Ubiquitous computing methods and apparatus

Ubiquitous computing methods and apparatus are disclosed. An example method includes determining a first setting to control an actuator; setting a first record in a record list, the first record including the first setting, a first immediacy of the first setting, and a first priority of the first setting; determining a second setting; setting a second record in the record list, the second record including the second setting, a second immediacy of the second setting, and a second priority of the second setting, the second priority being lower than the first priority; selecting the first record from the record list based on the first priority being higher than the second priority; deleting the second record from the record list based on the second immediacy; and outputting the first setting to control the actuator when a current setting of the actuator is different than the first setting.

FIELD OF THE DISCLOSURE

This disclosure relates generally to automated device control and, more particularly, to ubiquitous computing methods and apparatus.

BACKGROUND

Ubiquitous computing, or the “Internet of Things,” offers the opportunity to control networked devices that interact with people and affect the environments in which people live. User studies show that one of the major challenges of ubiquitous computing is designing complex technology that users can understand and interact with successfully, and with which users can feel comfortable.

The figures are not to scale. Wherever appropriate, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

Examples disclosed herein specify and implement control programs for ubiquitous computing devices in the form of features. In some examples, individual features of a device are independent of one another. That is, each feature satisfies a particular goal or requirement of the ubiquitous computing device. In some examples, multiple features run in parallel and the outputs of the features are selected to control the ubiquitous computing device according to the relative priorities of the features. Examples disclosed herein enhance the efficiency and effectiveness of ubiquitous computing devices by balancing between manual and automated control, while simplifying feature specification and feature implementation. For example, by adhering to a set of feature coordination rules, examples disclosed herein enable the rapid development and/or addition of features to ubiquitous computing devices and may be applied to many different control applications with little to no customization of feature coordination required.

Known devices have required intense customization of feature coordination to operate, and modifying the functionality of such devices requires ensuring that changes do not affect prior functionality. Such efforts are resource-intensive. In contrast, examples disclosed herein enable development of features independently of prior functionality, reducing the resources needed to improve ubiquitous computing devices after release (e.g., after installation in a consumer system).

As used herein, the term “ubiquitous computing device” refers to a device that processes inputs according to one or more specific behavioral requirements of the device to achieve a tangible result. Ubiquitous computing devices, as used herein, are often synonymous with the concept of the “Internet of Things” in which previously-dumb (i.e., non-computerized) devices are provided with processing capabilities and specialized intelligence to assist a user in the operation of the device.

As used herein, the term “feature” refers to the specification and/or implementation of an independent requirement of the behavior of a ubiquitous computing device. As used herein, the term “feature interaction” refers to a conflict between two or more features.

As used here, “manual” control refers to control in direct response to deliberate user requests or actions. Manual control can include electronic control (e.g., implemented by the control system), such as when a user requests unlocking of a door at a door lock system, enters a pass code, and is authenticated by the door lock system. Manual control of the system can also include mechanical control, such as when a user locks or unlocks the door with a key, thereby bypassing the electrical control by the door lock system. Mechanical control is not implemented by the electronic control, but the action can be detected by the electrical portion of the control system.

Examples disclosed herein provide ubiquitous computing according to a framework that improves the efficiency, reliability, and usability of potentially-complex device behaviors. Because the requirements for control of networked devices can reflect diverse purposes, situations, and/or levels of certainty about a current situation, examples disclosed herein specify and implement requirements independently. In some such examples, the outputs of features implementing such requirements are implemented at runtime according to assigned priorities.

Advantages of examples disclosed herein include simplification of implementing independent requirements in devices, making control of devices more flexible and/or extensible (e.g., because requirements can come from different sources), and/or enabling addition and/or deletion of control requirements at any time. Examples disclosed herein use priority to resolve conflicts among competing goals. As used herein, a feature with higher priority is more important than (e.g., takes precedence over and/or is more preferable for the purposes of controlling behavior than) a feature with lower priority. In some examples, priority is encoded in feature records using integer values.

Some examples disclosed herein handle feedback loops introduced by manual control of a ubiquitous computing device such that automated control of the device reaches quiescence (e.g., reaches a steady-state consistent with the manual control).

FIG. 1is a block diagram of an example ubiquitous computing device100to control an actuator102. The example actuator102may be, but is not necessarily, a part of the ubiquitous computing device100. The example actuator102ofFIG. 1can be any type of actuator, such as an electronic actuator. An example of an actuator102described below is an electronic door lock for a home. On the example electronic door lock, there are two access panels mounted by the door: one outside the house and one inside the house. Each example panel has buttons to request that the door be locked or unlocked, a keypad for entering passcodes, and a message display.

The example actuator102controls a controlled object103. In the example of a door lock, the controlled object103may be the locking mechanism, and the actuator102electronically manipulates the locking mechanism (e.g., via electromagnetic force, etc.).

The example ubiquitous computing device100ofFIG. 1includes a set of feature controllers106,108,110,112. Each of the example feature controllers106-112receives one or more input signals and generates a record to indicate a desired control action to be performed by the actuator102to control the controlled object103. While four feature controllers106-112are shown inFIG. 1, the ubiquitous computing device100may have any number of feature controllers106-112to implement behavioral requirements of the device.

The feature controllers106-112ofFIG. 1are assigned respective priority values. For example, the feature controller106may be assigned priority10, the feature controller108may be assigned priority3, the feature controller110may be assigned priority2, and the feature controller112may be assigned priority1. In some examples, one or more of the feature controllers106-112may have the same priority value. As discussed in more detail below, each of the example feature controllers106-112is provided with a control scheme (e.g., a control algorithm, a control program, etc.) that causes the feature controllers106-112to generate output commands based on respective inputs. An example implementation of one of the feature controllers106-112is described below with reference toFIG. 3.

In some other examples, one or more of the feature controllers106-112implement multiple features. For example, a feature controller106-112may be required to implement multiple different behavioral requirements of the ubiquitous computing device100. In some such examples, one or more of the different behavioral requirements have different priority constraints, and the constraints may conflict in such a way that the feature cannot fit anywhere in the priority order. To implement multiple features using one feature controller106-112, the feature controller106-112implements the different requirements as sub-features with different priority values under one feature type. Each feature and/or sub-feature is uniquely identified by a feature, priority pair.

Using the example of the electronic door lock, the feature controllers106-112implement the following behavior requirements as independent features:

Electronic Operation (EO): When a person requests a lock or unlock operation from an access panel, if that operation from that panel requires a passcode, read the passcode and check the entered passcode. If the operation is refused, send a message to the access panel. Otherwise, lock or unlock the door as requested. In the example below, the feature controller106implements the EO feature.

Hands-Free Entry (HFE): When sensors detect that a resident's car is arriving on the property, unlock the door so that the resident can enter easily (e.g., even when the resident is carrying packages). In the example below, the feature controller108implements the HFE feature.

Intruder Defense (ID): When sensors outside the house detect the possible presence of an intruder, lock the door and send “possible intruder detected” messages to the access panels. Keep the door locked until the sensors provide an “all clear” signal, at which time “all clear” messages are sent to the access panels. In the example below, the feature controller110implements the ID feature.

Night Lock (NL): In “night mode,” automatically lock the door after it has been unlocked for a defined period of time. Residents may set the time when “night mode” begins and ends. In the example below, the feature controller112implements the NL feature.

The example feature controllers106-112implement the respective ones of EO, HFE, ID, and NL. Door lock control may be complicated when the electronic door lock is battery-powered. Electronic control of the lock can fail (e.g., when the battery dies). To handle such situations, the example door lock permits mechanical or manual operation (e.g., using a physical key as a credential).

The example feature controllers106-112ofFIG. 1run concurrently. The outputs of the feature controllers106-112may be considered virtual actuator settings, because each feature controller106-112functions as if that feature controller106-112is controlling the object unilaterally via a dedicated actuator.

The example features controllers106-112populate a feature record cache114(e.g., a record list) with respective records116,118,120,122representing the virtual actuator settings. For example, the feature controller106generates a record116and provides the record to a feature coordinator124, which manages the feature record cache114as described in more detail below. In addition to virtual actuator settings, the records include other information, such as priority, to enable generation of a control signal (e.g., an actuator setting) to the actuator102.

Each of the example feature records116-122in the feature record cache114ofFIG. 1contains five items: a timestamp time; an actuator setting of setting; a mode setting mode; a feature having a data type of Feature; and a priority having a data type of Integer. Each feature record116-122generated and provided to the feature coordinator (except for records with a dontCare setting, which have no mode). These data items are discussed in more detail below.

The example feature coordinator124ofFIG. 1selects between the records116-122in the feature record cache114to determine how to control the actuator102. An example implementation of the feature coordinator124is described below with reference toFIG. 2.

To determine a desired output of the actuator102that corresponds to a particular behavioral requirement, the example feature controllers106-112receive input signals from one or more physical sensors126,128, one or more virtual sensors130,132,134, and/or one or more object state sensors136.

The physical sensors126,128may include any sensor that measures or detects physical quantities (e.g., temperature, pressure, motion, presence of chemicals, chemical composition, sound, magnetism, light, and/or any other kind of sensor). The type(s) of physical sensors126,128are determined based on the type or purpose of the ubiquitous computing device100. In some examples, one or more of the physical sensors126,128is physically separate and/or remote from the ubiquitous computing device100. In some such examples, the separated physical sensor126,128communicates its output to the ubiquitous computing device100via a communication network (e.g., a wireless network, a wired connection, etc.).

The example virtual sensors130-134ofFIG. 1receive signals from one or more of the example physical sensors126,128and/or the state of the actuator102from the object state sensor(s)136. The example virtual sensors130-134are models that generate virtual sensor values that represent the output of virtual sensors (e.g., soft sensors, proxy sensors, inferential sensors, etc.), and make inferences of the state of a quantity based on input signals.

The example object state sensor136ofFIG. 1is a physical sensor (e.g., another one of the physical sensors126,128) that senses the current state of the controlled object103(e.g., open/closed, position, etc.). For example, the state of the controlled object103(e.g., locked or unlocked, in the door lock example) may not be the most recent state set by the feature coordinator124due to mechanical or manual operation of the actuator102and/or the controlled object103. In the door lock example, a physical sensor (e.g., a Hall effect sensor or other type of sensor) may be used to determine whether a locking mechanism is in a locked state or an unlocked state. In some examples, the feature coordinator124sends the output actuator setting provided to the actuator102to the virtual sensor models130-134and/or to the feature controllers106-112. For example, the actuator setting output by the feature coordinator124may be compared with the value output by the object state sensor136to detect failure of the actuator102and/or to detect changes in the controlled object103having external causes.

In the door lock example, the feature controllers106-112and the feature coordinator124use the actuator settings specified in an enumerated set {lock, unlock}. The door lock (e.g., the controlled object103) has a single sensor (e.g., the object state sensor136), which draws its sensor output values from an enumerated set {locked, unlocked} or an equivalent set (e.g., {0, 1}). In this example, the object state sensor136outputs a value only when the state of the door lock (e.g., the actuator102) changes. However, the example object state sensor136may additionally or alternatively make periodic readings of the lock state and output the resulting value locked or unlocked.

The example ubiquitous computing device100ofFIG. 1operates according to the following five rules. The example rules below may be used to implement the feature controllers and/or feature coordinator for a ubiquitous computing device having any combination of features and/or actuators.

Rule 1: All actuator settings by the feature controllers106-112(e.g., virtual actuator settings) are persistent. For example, a feature controller106does not emit a setting unlock to as a single instance command to “unlock the door now.” Instead, the example feature controller106emits a setting unlock to mean “unlock the door now and keep it unlocked until I emit a different setting” (keeping in mind that the feature controller106is independent and behaves as if it has sole control over the actuator102). The example ubiquitous computing device100complies with Rule 1 because, in the door lock example, if settings were interpreted as instantaneous events, then immediately after the feature controller106above unlocks the door, a lower-priority feature (e.g., feature controller108) could lock it again, which could defeat the purpose of using different priorities for the feature controllers106-112.

As a result of Rule 1 (i.e., persistence of actuator settings), when a feature controller106outputs a setting, the output setting becomes the current setting of the feature controller106. The current setting of the feature controller106persists until the current setting is replaced by another (e.g., more recent) setting of that feature controller106. In some examples, the current setting has a fixed duration and is replaced when that duration expires. In some other examples, current settings persist until a new sensor value is received at the feature controller106.

Rule 2: The type(s) of the virtual actuator settings by the feature controllers106-112must be the same types as the corresponding real settings, plus a reserved value dontCare. The dontCare value means that the feature controller106-112is not attempting to exert control over the actuator setting. Rule 2 occurs due to the use of persistent actuator settings under Rule 1. Because all virtual actuator settings are persistent, if the highest priority feature controller (e.g., the feature controller106) were always to emit settings that exert control over the actuator102, then none of the other feature controllers108-112would ever be able to exert control or take effect. The dontCare setting, when output by a feature controller106, create windows of opportunity during which lower-priority feature controllers108-112can exert control over the actuator102.

Replacing a real (e.g., enumerated, or non-dontCare) virtual actuator setting with a dontCare may be referred to as “canceling” the virtual actuator setting. In the example ofFIG. 1, the feature coordinator124does not set records containing explicit dontCare settings feature record cache114. Instead, to cancel a virtual actuator setting, the example feature coordinator124deletes the corresponding feature record116from the feature record cache114upon receiving a feature record116from the feature controller106having the same feature and priority and a dontCare virtual actuator setting. Thus, while the example feature controller106maintains a dontCare setting, the feature record cache114is devoid of a feature record116corresponding to that feature controller106. As used herein, deleting a feature record refers to removing the record from the feature record cache114, marking the feature record as irrelevant and/or unusable, and/or otherwise ignoring or not using the feature record.

Rule 3: If multiple feature controllers106-112have the same priority value, then the most recent virtual actuator setting by those feature controllers106-112having the same priority value takes precedence. Because two or more of the feature controllers106-112may have multiple current settings that may conflict at a given time, Rule 3 provides a way to choose which of those feature controllers106-112takes precedence. Rule 3 is consistent with the fact that the most recent virtual actuator setting by any individual feature controller106-112takes precedence over earlier settings by that feature controller106-112.

Rule 4: If all virtual actuator settings by the feature controllers106-112become dontCare, the actuator setting output by the feature coordinator124to the actuator102is left unchanged. Persistent settings according to Rule 1 may be uncomfortable for users who do not have definite ideas about how long a setting should last. For example, when a person uses the Electronic Operation of the door lock example to unlock his front door in the morning, his intention may be to leave it open all day for residents and visitors to go in and out. In such a case, an unlock duration such as one minute is far too short. On the other hand, if the unlock setting lasts until the next manual lock operation then, because manual operations are given the highest priority in this example, the door will remain unlocked even when Intruder Defense has detected an intruder and is attempting to lock it. Rule 4 provides an indefinite duration, which keeps the door unlocked until something happens to make locking desirable.

Under Rule 4, the duration of the manual unlock setting may be short (e.g., one minute, two minutes, etc). When the minute expires, the feature controller106implementing Electronic Operation deletes the feature record116and has a dontCare virtual actuator setting. However, if all of the other feature controllers108-112also have dontCare settings in force (e.g., the feature record cache114is empty), then the actuator102will retain an unlock setting under Rule 4. The actuator102will lock only when one of the feature controllers106-112outputs a new virtual actuator setting lock, which is then implemented by the feature coordinator124.

Rule 5: Each virtual actuator setting in the enumerated set (e.g., {lock, unlock}), but not the dontCare setting, has a mode setting (e.g., an immediacy) that is either immediate or eventual. In the example ofFIG. 1, the feature records116-122specify the mode setting in association with the virtual actuator output setting specified in the feature record116-122. If the mode setting is eventual, the corresponding virtual actuator setting is intended to take effect as soon as possible and whenever possible (e.g., subject to priority rules). If the mode setting is immediate, the corresponding virtual actuator setting is intended to take effect immediately. However, when the mode setting is immediate but the virtual actuator setting (e.g., an unlock setting in the feature record122) cannot take effect immediately (e.g., due to priority rules), or if the virtual actuator setting takes effect but is preempted by a different virtual actuator setting from a different feature record (e.g., feature records116-120) before the feature record122is canceled by the corresponding feature controller112, then the feature record122having the immediate mode setting is canceled by the feature coordinator124.

Rule 5 makes the behavior of the example ubiquitous computing device100predictable to users. For example, if a user requests a manual operation, it is acceptable for the ubiquitous computing device100to refuse the request (e.g., due to programmed behaviors of the ubiquitous computing device100). However, it may be unacceptable for the ubiquitous computing device100to ignore the request, after which the user may walk away, and then grant the request at a later time when the user may not be aware of the grant by the ubiquitous computing device100. Such behavior results in a lack of trust in the ubiquitous computing device100by the user and undermines the perceived utility of the ubiquitous computing device100.

In an example of operation of the door lock under Rules 1-5 having the example feature controllers106-112and the feature coordinator124, a resident of a household in which the door lock is installed drives home and is detected by Hands-Free Entry via one or more physical sensors126,128and/or virtual sensors130-134. The feature controller110implementing HFE generates a feature record120with an unlock virtual actuator setting. The example feature record120for HFE has a duration of 3 minutes, due to uncertainties about how long it will take the resident to get to the door.

Around the same time, motion detectors (e.g., physical sensors126,128and/or virtual sensors130-134) in the back of the house trigger the feature controller108implementing Intruder Defense to generate a feature record118having a lock virtual actuator setting. The feature controller108(e.g., Intruder Defense) has a higher priority (e.g., 3) than the Hands-Free Operation, so the feature coordinator124determines that the actuator setting is to be lock and, therefore, the controlled object103remains in a locked state. The user finds that the door is locked and sees an intruder alert on the door panel. When the user goes to the back of the house, he finds that a squirrel has been sensed as an intruder. When the squirrel is removed, the feature controller108generates a dontCare virtual actuator setting and, thus, deletes the feature record118asserting a lock actuator setting. If the feature record118is deleted within the 3 minute duration of the feature record120, the example feature coordinator124determines that the actuator setting should be unlock and outputs an unlock signal to the actuator102to cause the actuator102to unlock the controlled object103.

The immediate mode setting may be used to, for example, implement manual operations electronically. If manual operations are not immediately successful the user may then not want or expect them, so they should be canceled. In the above example the hands-free unlock may be in the immediate mode setting because, while hands-free unlock is not a manual operation as defined above because the resident did not explicitly request that the door be unlocked, hands-free unlock is similar to a manual operation in that the hands-free unlock feature is intended for the immediate benefit of a user who will expect it to occur. If hands-free unlock has an immediate mode setting, the feature record120is canceled by the feature coordinator124when the feature record120arrives at the coordinator (if Intruder Defense is already triggered) and/or as soon as the feature controller108sets the feature record118at the feature record cache114(e.g., when the Intruder Defense is triggered).

Additionally or alternatively, the immediate mode setting may be used for mechanical operations of the door lock with a knob and/or key. When a mechanically-operated actuator setting is over-ridden by some other actuator setting, the mechanically-operated actuator setting is canceled and can have no further effect.

Another example of the immediate mode setting includes implementing a feature whose purpose can be achieved in alternative ways (e.g., using alternative actuators). For example, if a first actuator setting of the feature cannot be honored immediately, the example feature may try an alternative actuator or other solution rather than waiting for possible eventual success.

FIG. 2is a more detailed block diagram of the example feature coordinator124ofFIG. 1. The example feature coordinator124ofFIG. 2includes a feature record manager202, a feature record selector204, a feature record pruner206, an actuator output determiner208, an actuator output comparator210, an actuator output cache212, and an actuator signal generator214.

The example feature record manager202ofFIG. 2receives feature records116-122from the feature controllers106-112ofFIG. 1via a toCoord data stream. The example feature record manager202reads the feature records116-122as they are received and controls the feature records116-122stored in the feature record cache114based on the data in the feature records116-122(e.g., actuator setting, mode setting, feature, priority, and time).

Except for different Setting types (e.g., different sets of enumerated actuator setting types) and different Feature types (e.g., different sets of enumerated feature types) appropriate to different actuators, the operation of the feature coordinator124ofFIGS. 1 and 2may be highly similar or identical for different types of ubiquitous computing devices100. The example feature controllers106-112perform a toCoord!setting,mode action that transmits the actuator setting and mode setting in a record with the correct feature, priority, and time, and writing the record to a toCoord data stream. The toCoord data stream provides the feature records116-122from all of the feature controllers106-112to the feature coordinator124, which processes the feature records116-122to add and/or remove feature records116-122from the feature record cache114. In this example, it is assumed that records of the toCoord stream are ordered by time (although adjacent records can have the same time). The example feature record feature record manager202processes the feature records116-122in the order they are received at the feature coordinator124.

The example feature record cache114may be considered a state of the feature coordinator124. The example feature record manager202initializes the feature record cache114to an empty list. As the feature record manager202processes records received in the toCoord stream, the feature record manager202controls the state of the feature record cache114by adding and/or removing feature records116-122. Thus, the example feature record cache114contains the current actuator setting of all of the feature/priority pairs generated by the example feature controllers106-112, where dontCare cause feature records116-122to be removed. In the example ofFIG. 2, the feature record manager202also orders the feature records116-122in the feature record cache114by priority (e.g., highest priority to lowest priority or vice versa).

In the example ofFIG. 2, the feature record cache114has the following properties: 1) no record in the list has dontCare as its actuator setting. (e.g., feature records116-122having dontCare actuator settings are not stored explicitly in the feature record cache114); 2) for each feature/priority pair, there is at most one record with that combination of feature and priority (e.g., the current actuator setting corresponding to that feature); 3) the records are ordered by priority, with the highest priority first (e.g., adjacent records can have the same priority because priority values are not unique); and 4) within a group of feature records having the same priority, the feature records are ordered by time, with the highest time (e.g., the most recent record) first (e.g., adjacent records can have the same time because times are not unique).

Second, there is a variable oldSet:Setting. The value of oldSet:Setting is the last actuator setting sent by the actuator signal generator214to the actuator102. This excludes its initial value dontCare, which is not sent to the actuator102.

The example feature record manager202processes each input feature record116-122in the toCoord data stream by determining whether the input feature record116-122matches a feature record stored in the feature record cache114. The input feature record116-122matches a stored record in feature record cache114when input feature record116-122and the stored record have the same feature and priority.

When the input feature record116-122does not match any stored records and the actuator setting of the input feature record116-122has an actuator setting of dontCare, the example feature record manager202discards the input feature record116-122. When the input feature record116-122does not match any stored records and the actuator setting of the input feature record116-122has an enumerated actuator setting (e.g., is not dontCare), the feature record manager202inserts the input feature record116-122into the feature record cache114in the order according to the priority and time of the input feature record116-122.

When the feature record manager202identifies a feature record116-122in the feature record cache114that matches the input feature record116-122and the actuator setting of the input feature record116-122is dontCare, the example feature record manager202deletes the matching feature record116-122from the feature record cache114(and does not replace it). As a result, the feature controller106-112that generated the input feature record116-122no longer has a feature record in the feature record cache114. When the feature record manager202identifies a feature record116-122in the feature record cache114that matches the input feature record116-122and the actuator setting of the input feature record116-122is an enumerated actuator setting (e.g., is not dontCare), the feature record manager202deletes the matching feature record116-122and inserts the input feature record116-122into the feature record cache114in the order according to the priority and time of the input feature record116-122.

In some examples, the data stream(s) toCoord that provide feature records116-122from the feature controllers106-112to the feature coordinator124are not necessarily delivered in timestamp order. When data stream(s) cannot be relied upon to deliver feature records in timestamp order, the example feature coordinator124adds a further requirement for deleting and/or replacing stored feature records in the feature record cache114based on input feature records116-122. That is, when the feature record manager202identifies a feature record116-122in the feature record cache114that matches the input feature record116-122, the example feature record manager202deletes or replaces the matching feature record116-122from the feature record cache114only when the timestamp of the input feature record116-122is more recent (e.g., has a later time) than the timestamp of the matching feature record116-122. If the input feature record116-122has an earlier timestamp than the matching feature record116-122, the input feature record116-122is obsolete and is discarded.

The example feature record selector204ofFIG. 2selects the first-ordered feature record from the feature record cache114(e.g., the feature record116-122having the highest priority, the feature record116-122having the most recent time when multiple feature records have a highest priority).

When the feature record selector204selects a first feature record (e.g., the feature record116ofFIG. 1), the example feature record pruner206ofFIG. 2removes any feature records in the feature record cache114that have an immediate mode setting and are preempted by the selected feature record.

The example actuator output determiner208ofFIG. 2determines an actuator setting to be output to the actuator102based on the selected feature record. For example, the actuator output determiner208may determine the actuator setting stored in the selected feature record116and store the actuator setting in a temporary variable newSet:setting. In some examples, the feature record pruner206only removes feature records that have an immediate mode setting and an actuator setting that is not equal to the newSet:setting variable.

The example actuator output comparator210ofFIG. 2compare a current setting of the output device to the first output setting determines whether an output signal is necessary by comparing a most recent actuator setting applied to the actuator102(e.g., oldSet:setting) that is stored in the actuator output cache212. When the actuator output comparator210determines that newSet:setting is equal to oldSet:setting, a new signal to the actuator102is not needed. In contrast, when the actuator output comparator210determines that newSet:setting is not equal to oldSet:setting, the example actuator output comparator210instructs the actuator signal generator214to generate a signal to implement newSet:setting at the actuator102.

The example actuator signal generator214generates a signal based on the type of the actuator102and the actuator setting to be implemented. When the actuator signal generator214outputs the signal to the actuator102, the example actuator signal generator214also updates the oldSet:setting variable in the actuator output cache212.

The operation of the example feature coordinator124ofFIGS. 1 and/or 2may be restated as: a feature's current setting (excluding dontCare) at a priority p and with a timestamp t is in force unless another feature record116-122(e.g., an output from another feature controller106-112) has a different actuator setting at a priority greater than p, another feature record116-122(e.g., an output from another feature controller106-112) has a different current setting at priority p, and with time t or more recent than t, or the actuator setting has an immediate mode setting, and since time t a different actuator setting has been applied.

Using the example features described above (e.g., EO, ID, HFE, and NL), the behavior of the feature coordinator124is consistent with the priorities of the features. For example, the actuator setting (e.g., lock or unlock) of the feature controller106for EO is in force, when EO does not have a dontCare actuator setting. The actuator setting (e.g., lock) of the feature controller108for ID is in force unless EO has an unlock setting in force (e.g., due to the higher priority of feature records associated with EO). The actuator setting (e.g., unlock) of the feature controller110for HFE is in force unless, since the last comingHome event triggering the feature controller110to set an unlock actuator setting, EO or ID has had a lock setting in force. The actuator setting (e.g., lock) of the feature controller112for NL is in force unless EO and/or HFE have an unlock setting in force. If none of the feature controllers106-112have a current lock or unlock actuator setting, then the most recent actuator setting in force continues to stay in force.

In some examples, feature controllers can be added (e.g., by a user) to provide guaranteed behaviors. For example, because the feature controllers106-112are independent and the feature coordinator124manages the interactions between the feature controllers106-112, a guaranteed behavior can be added as another independent feature controller that sets feature records having a high priority (e.g., the highest priority). Adding a feature controller need not affect other feature controllers, and may not necessarily even require the user to understand the operations of the other feature controllers.

FIG. 3is a block diagram of an example implementation of a feature controller300that may be used to implement any of the feature controllers106-112ofFIG. 1. The example feature controller300ofFIG. 3includes a sensor value reader302, an actuator output determiner304, a feature record generator306, and a feature configuration308.

The example sensor value reader302ofFIG. 3receives sensor values as inputs. For example, the sensor value reader302may receive physical sensor values (e.g., signals, data streams, etc.) from the example sensors126,128, virtual sensor values from the virtual sensor models130-134, and/or a controlled object status from the object state sensor(s)136ofFIG. 1.

The example actuator output determiner304determines an actuator setting (e.g., actuator settings from an enumerated list or dontCare) based on the received sensor values. The actuator output determiner304for the example feature controller300is specific to the behavioral requirement that is implemented by the feature controller300. Examples of state diagrams that may be used to implement actuator output determiners304for the door lock example (e.g., NL, HFE, ID, EO) are described below with reference toFIGS. 4A-4D.

In some examples, the actuator output determiner304performs a determination of an appropriate actuator setting each time a feature record116-122is received. In other examples, the actuator output determiner304performs the determination at regular and/or irregular intervals using the most recent sensor values received at the sensor value reader302.

The example feature record generator306generates a feature record (e.g., the feature records116-122ofFIG. 1) using the actuator setting determined by the actuator output determiner304. The feature record generator306further includes a mode setting (e.g., immediate or eventual), a priority value, a timestamp time, and the feature type. The example feature configuration308stores the mode setting (e.g., immediate or eventual), the priority value, and/or the feature type that is assigned to the example feature controller300.

While example manners of implementing feature controllers106-112and the feature coordinator ofFIG. 1are illustrated inFIGS. 2 and 3, one or more of the elements, processes and/or devices illustrated inFIGS. 1, 2, and/or3may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example actuator102, the example feature controllers106-112, the example feature record cache114, the example feature coordinator124, the example sensors126,128, the example virtual sensor models130-134, the example object state sensor136, the example feature record manager202, the example feature record selector204, the example feature record pruner206, the example actuator output determiner208, the example actuator output comparator210, the example actuator output cache212, the example actuator signal generator214, the example sensor value reader302, the example actuator output determiner304, the example feature record generator306, the example feature configuration308and/or, more generally, the example ubiquitous computing device100ofFIG. 1may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example actuator102, the example feature controllers106-112, the example feature record cache114, the example feature coordinator124, the example sensors126,128, the example virtual sensor models130-134, the example object state sensor136, the example feature record manager202, the example feature record selector204, the example feature record pruner206, the example actuator output determiner208, the example actuator output comparator210, the example actuator output cache212, the example actuator signal generator214, the example sensor value reader302, the example actuator output determiner304, the example feature record generator306, the example feature configuration308and/or, more generally, the example ubiquitous computing device100could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example actuator102, the example feature controllers106-112, the example feature record cache114, the example feature coordinator124, the example sensors126,128, the example virtual sensor models130-134, the example object state sensor136, the example feature record manager202, the example feature record selector204, the example feature record pruner206, the example actuator output determiner208, the example actuator output comparator210, the example actuator output cache212, the example actuator signal generator214, the example sensor value reader302, the example actuator output determiner304, the example feature record generator306, and/or the example feature configuration308is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example ubiquitous computing device100ofFIG. 1may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIGS. 1, 2, and/or3, and/or may include more than one of any or all of the illustrated elements, processes and devices.

In the examples ofFIGS. 4A-4D, reading a record from a stream uses the notation streamName ? recordType, and writing a record to a stream uses the notation streamName ! record. The guard of a transition is separated from its actions by a slash.

FIG. 4Ais an example state diagram400that may be implemented by the example actuator output determiner304for the example feature controller106ofFIG. 1to control the example Electronic Operation feature discussed above for a door lock ubiquitous computing device. InFIG. 4A, the stream names panelIn and panelOut are used generically, because in the door lock example there are two access panels on the door lock, and the lock and/or unlock requests are received from one of the panels at a time.

The example state diagram400determines whether the virtual actuator setting output to the feature coordinator124is to be lock, unlock, or dontCare based on a panelIn variable, an opAuthorized variable, and an EOtimeout variable (e.g., from a combination of physical sensor(s)126,128, virtual sensor model(s)130-134, and/or the object state sensor(s)136ofFIG. 1). The panelln variable indicates whether a user has requested the controlled object103ofFIG. 1to be locked or unlocked (e.g., based on an input panel to the ubiquitous computing device100) and/or whether the user is authorized to perform the operation (e.g., whether a correct authorization code has been entered).

In the example state diagram400ofFIG. 4A, the possible virtual actuator settings lock, unlock, or dontCare are represented as respective states402,404,406. When the actuator output determiner304receives an input (e.g., from the sensor value reader302ofFIG. 3), the actuator output determiner304traverses the state diagram400based on the values of the panelIn variable (e.g., requestLock, requestUnlock), the opAuthorized variable (e.g., yes, no), and/or the EOtimeout variable (e.g., timeout, no).

In the example state diagram400, when the state changes to the lock state402(from any of the states402-406), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a lock actuator setting and an immediate mode setting. When the state changes to the unlock state404(from any of the states402-406), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have an unlock actuator setting and an immediate mode setting. When the state changes to the dontCare state406(from any of the states402-406), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a dontCare actuator setting (and the mode setting is irrelevant).

FIG. 4Bis an example state diagram410that may be implemented by the example actuator output determiner304for the example feature controller108ofFIG. 1to control the example Hands Free Entry feature discussed above for a door lock ubiquitous computing device. The example state diagram410determines whether the virtual actuator setting output to the feature coordinator124is to be unlock or dontCare based on a HFEsensors variable and a HFEtimeout variable (e.g., from a combination of physical sensor(s)126,128, virtual sensor model(s)130-134, and/or the object state sensor(s)136ofFIG. 1). The HFEsensors variable indicates whether a user is approaching the house. The HFEtimeout variable indicates whether an HFE timer has expired.

In the example state diagram410ofFIG. 4B, the possible virtual actuator settings unlock or dontCare are represented as respective states412,414. When the actuator output determiner304receives an input (e.g., from the sensor value reader302ofFIG. 3), the actuator output determiner304traverses the state diagram410based on the values of the HFEsensors variable (e.g., comingHome, no) and/or the HFEtimeout variable (e.g., timeout, no).

In the example state diagram410, when the state changes to the unlock state412(from the dontCare state414), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have an unlock actuator setting and an immediate mode setting. When the state iterates the unlock state412, the example actuator output determiner304does not output a new feature record (e.g., because the door lock is already unlocked). When the state changes to the dontCare state414(from the unlock state412), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a dontCare actuator setting (and the mode setting is irrelevant).

FIG. 4Cis an example state diagram420that may be implemented by the example actuator output determiner304for the example feature controller110ofFIG. 1to control the example Intruder Detection feature discussed above for a door lock ubiquitous computing device. The example state diagram420determines whether the virtual actuator setting output to the feature coordinator124is to be lock or dontCare based on an IDsensors variable (e.g., from a combination of physical sensor(s)126,128, virtual sensor model(s)130-134, and/or the object state sensor(s)136ofFIG. 1). The IDsensors variable indicates whether intrusion detection sensors have identified a possible intruder near the house.

In the example state diagram420ofFIG. 4C, the possible virtual actuator settings lock or dontCare are represented as respective states422,424. When the actuator output determiner304receives an input (e.g., from the sensor value reader302ofFIG. 3), the actuator output determiner304traverses the state diagram420based on the value of the IDsensors variable (e.g., intruderDetected, allClear).

In the example state diagram420, when the state changes to the lock state422(from the dontCare state424), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a lock actuator setting and an eventual mode setting. When the state changes to the dontCare state424(from the lock state422), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a dontCare actuator setting (and the mode setting is irrelevant).

FIG. 4Dis an example state diagram430that may be implemented by the example actuator output determiner304for the example feature controller112ofFIG. 1to control the example Night Lock feature discussed above for a door lock ubiquitous computing device. The example state diagram430determines whether the virtual actuator setting output to the feature coordinator124is to be lock or dontCare based on an NLtimer variable (e.g., from a virtual sensor model130-134ofFIG. 1such as a timer or clock). The NLsensors variable indicates whether night mode is active (e.g., whether a current time is within a designated night time range).

In the example state diagram430ofFIG. 4D, the possible virtual actuator settings lock or dontCare are represented as respective states432,434. When the actuator output determiner304receives an input (e.g., from the sensor value reader302ofFIG. 3), the actuator output determiner304traverses the state diagram430based on the value of the NLtimer variable (e.g., nightBegins, nightEnds).

In the example state diagram430, when the state changes to the lock state432(from the dontCare state434), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a lock actuator setting and an eventual mode setting. When the state changes to the dontCare state434(from the lock state432), the example actuator output determiner304determines that the feature record to be generated by the feature record generator306(e.g., for transmission via the toCoord data stream) is to have a dontCare actuator setting (and the mode setting is irrelevant).

FIG. 5is an example state diagram500that may be implemented by a virtual sensor model130-134of the ubiquitous computing device100ofFIG. 1. The example state diagram500ofFIG. 5represents a detected state of the door lock due to a mechanical lock or unlock operation. The example state diagram500includes four states: locked502, unlocked504, unlock Expected506, and lock Expected508. The virtual sensor model130-134implementing the state diagram500receives input data streams toDoor (e.g., an actuator output from the feature controller106-112implementing the MO feature) and fromDoor (e.g., from the object state sensor136). The example feature records116-122that include the MO feature have the same priority values as the example feature records116that include the EO feature.

The example state diagram500(e.g., via the virtual sensor model) may initially be in the locked state502or the unlocked state504. When the state diagram500detects an input “unlocked” on the data stream fromDoor (e.g., from the object state sensor136) while in the locked state502, the example state diagram500transitions from the locked state502to the unlocked state504and the virtual sensor model outputs a mechUnlock virtual sensor value to the toMO data stream (e.g., to the feature controllers106-112). Conversely, when the state diagram500detects an input “locked” on the data stream fromDoor (e.g., from the object state sensor136) while in the unlocked state504, the example state diagram500transitions from the unlocked state504to the locked state502and the virtual sensor model outputs a mechLock virtual sensor value to the toMO data stream (e.g., to the feature controllers106-112).

When the state diagram500detects an input “unlock” on the data stream toDoor (e.g., from one of the feature controllers106-112) while in the locked state502, the example state diagram500transitions from the locked state502to the unlock Expected state506. Then, when the state diagram500detects an input “unlocked” on the data stream fromDoor (e.g., from the object state sensor136) while in the unlock Expected state506, the example state diagram500transitions from the unlock Expected state506to the unlocked state504.

Conversely, when the state diagram500detects an input “lock” on the data stream toDoor (e.g., from one of the feature controllers106-112) while in the unlocked state504, the example state diagram500transitions from the unlocked state504to the lock Expected state508. Then, when the state diagram500detects an input “locked” on the data stream fromDoor (e.g., from the object state sensor136) while in the lock Expected state508, the example state diagram500transitions from the lock Expected state508to the locked state502.

When the feature controller106-112implementing the MO feature receives a mechUnlock from the virtual sensor model130-134implementing the state diagram500, the feature controller106-112will echo the mechanical operation electronically by sending a feature record116-122that includes an unlock actuator setting and an immediate mode setting to the toCoord data stream. The feature coordinator124inserts the feature record into the feature record cache114and prevent lower-priority locks until the 1-minute duration is over. When the 1-minute duration is over the MO feature controller will send a feature record containing a dontCare actuator setting to the toCoord data stream. The updated record may cause the feature coordinator124to, for example, lock the door in accordance with the actuator setting of the NightLock feature controller112.

FIG. 6is a flowchart600illustrating an example manner in which the ubiquitous computing device100ofFIG. 1may reach quiescence following a mechanical operation of the ubiquitous computing device100. The example flowchart600represents the respective states of a door lock sensor602(e.g., the object state sensor136ofFIG. 1), the virtual sensor model604representing the state of the door (e.g., the state diagram500ofFIG. 5, the virtual sensor model130-134ofFIG. 1), the MO feature controller606(e.g., the feature controller106-112implementing the MO feature), and the feature coordinator124ofFIG. 1. The example flowchart600ofFIG. 6also includes a time axis608that shows the chronological order of the flowchart600.

At a first time610, the door lock sensor602is in a locked state, the virtual sensor model604is in a locked state, the MO feature606has a dontCare actuator setting, and the feature coordinator124has an oldSet variable=lock. At a second time612, a mechanical unlock operation of the controlled object103occurs that places the door lock sensor602in an unlocked state. The example virtual sensor model604receives an input fromDoor (e.g., from the object state sensor136) with an unlocked value. As described with reference to the state diagram500ofFIG. 5, the virtual sensor model604outputs a mechUnlock virtual sensor value via a toMO data stream to the feature controller606.

The example feature controller606receives the input sensor value. The example actuator output determiner304of the feature controller606determines the virtual actuator setting of the feature controller606to be unlock. The example feature record generator306of the feature controller606generates a feature record having the unlock actuator setting and an immediate mode setting. The feature controller606outputs the feature record to the example feature coordinator124via the toCoord data stream. Based on the priority and/or time values of the feature record (as specified in the feature record by the feature controller606), the example feature coordinator124determines the actuator setting to the actuator102to be unlock and generates an output signal to the actuator102. The example feature coordinator124then sets the oldSet variable of the feature coordinator124to oldSet=unlock.

Because the controlled object103is already unlocked and the door lock sensor602has detected the unlocked state, the command from the feature coordinator124does not cause any change to the controlled object103by the actuator102or to the state sensed by the door lock sensor602. Thus, as shown inFIG. 6, the ubiquitous computing device100reaches quiescence after external stimuli cause changes to the state of the ubiquitous computing device100, the actuator102, and/or the controlled object103.

In some examples, the feature controllers106-112ofFIG. 1receive sensor values (e.g., real sensor values, virtual sensor values) from multiple controlled objects. Additionally or alternatively, the example ubiquitous computing device100may include multiple feature coordinators that correspond to multiple actuators. In some such examples, any of the feature controllers106-112may send actuator settings to any of the multiple feature coordinators to control the corresponding actuators.

In some examples, the feature coordinator124includes one or more timers. In some such examples, feature records further include a duration data item in addition to the five data items discussed above (i.e., actuator setting, mode setting, time, priority, feature). When the feature coordinator124receives a feature record, the feature coordinator124sets a timer for the duration stored in the feature record. The feature coordinator124removes the feature record from the feature record cache114if the timer times out the feature record is still in the feature record cache114(e.g., has not been preempted or deleted by the feature coordinator124based on a more recent feature record).

In some examples, the feature controllers106-112are not required to use actuator setting values taken from enumerated sets. For example, when one or more ubiquitous computing devices100control light fixtures in a home, the actuator settings may include a contiguous range. In some such examples, when the actuator setting is not dontCare, the actuator setting is a lower bound, an upper bound, or both. In other words, an actuator setting is a subrange of a total range of a light fixture. Such ranges may be stored as actuator settings in the feature record cache. The example feature coordinator124may then compute an output actuator setting by attempting to satisfy all of the subranges in the feature records in the feature record cache, and use the priority values of the feature records to resolve any conflicts that may exist between subranges. The feature coordinator124may further cancel feature records having an immediate mode setting and actuator setting subranges that are incompatible with the computed range. In some such examples, the feature coordinator124only sends a new actuator setting when the oldSet value is outside the newSet computed subrange.

In some examples, the feature coordinator124informs the feature controllers106-112whether the actuator setting set by that feature is in force or not. For example, feature controllers106-112that have alternative ways of achieving the behavioral requirement corresponding to the feature controller106-112may use such information from the feature coordinator124to invoke alternative ways of achieving their goals when appropriate.

While the examples disclosed herein use data streams, other communication methods between the feature controllers106-112, the feature coordinator124, and/or the sensors126-136may be used. For example, inputs to the feature controllers106-112and/or to the feature coordinator124may be synchronized to avoid a race condition that could lead transient and/or fluctuating control of the actuator102. Additionally or alternatively, the feature controllers106-112and/or the feature coordinator124may be configured to process data in batches.

Flowcharts representative of example machine readable instructions for implementing the feature controllers106-112, the example feature coordinator124and/or, more generally, the ubiquitous computing device100ofFIGS. 1, 2, and/or3are shown inFIGS. 7, 8, and 9. In this example, the machine readable instructions comprise programs for execution by a processor such as the processor1012shown in the example processor platform1000discussed below in connection withFIG. 10. The programs may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor1012, but the entire programs and/or parts thereof could alternatively be executed by a device other than the processor1012and/or embodied in firmware or dedicated hardware. Further, although the example programs are described with reference to the flowcharts illustrated inFIGS. 7, 8, and 9, many other methods of implementing the example feature controllers106-112, the example feature coordinator124and/or, more generally, the ubiquitous computing device100may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

FIG. 7is a flowchart representative of example machine readable instructions700which may be executed by the example ubiquitous computing device100ofFIG. 1to control the output of an actuator102.

The example ubiquitous computing device100ofFIG. 1generates a feature record116-122including an actuator setting and a priority value (e.g., using one of the feature controllers106-112,300ofFIGS. 1 and/or 3) (block702). The actuator setting is a virtual actuator setting that the feature controller106-112is attempting to enforce at the actuator102. The priority value represents a relative priority given to the feature controller106-112that is based on the relative importance of the behavior being implemented by the feature controller106-112.

The example ubiquitous computing device100ofFIG. 1determines whether additional feature controllers106-112are to generate additional feature records116-122(block704). If additional feature controllers106-112are generating feature records116-122(block704), control returns to block702to generate another feature record116-122via another feature controller106-112.

When no additional feature controllers106-112are to generate feature records (block704) (e.g., all feature controllers106-112have been given the opportunity to generate a feature record116-122, an interrupt has been issued to cause the feature coordinator124to process the feature records116-122, etc.), the example feature record manager202of the feature coordinator124ofFIGS. 1 and/or 2selects a feature record116-122from the feature controllers (block706). For example, the feature record manager202may select a feature record116-122from the data stream toCoord discussed above.

The example feature record manager202processes the selected feature record116-122(block708). Processing the feature record116-122results in inserting, deleting, and/or replacing one or more feature record(s)116-122in the feature record cache114. The example feature record manager202orders the feature records116-122stored in the feature record cache114according to the priority values and the times of the stored feature records116-122(block710). For example, the feature record manager202may order the records first by highest-priority to lowest-priority and then by most-recent time to least-recent time.

The example feature record selector204ofFIG. 2selects the first-ordered feature record116-122from the feature record cache114(block712). For example, the feature record selector204may select the feature record116-122in the feature record cache114having the highest priority value or, if multiple feature records116-122have a same highest priority value, the most recent of those feature records116-122.

The example feature record pruner206ofFIG. 2determines whether any non-selected records in the feature record cache114have immediate mode settings (block714). If any non-selected records in the feature record cache114have immediate mode settings (block714), the example feature record pruner206deletes those non-selected records in the feature record cache114that have immediate mode settings (block716).

After deleting the feature records116-122that have immediate mode settings (block716), or if none of the non-selected records in the feature record cache114have immediate mode settings (block714), the example actuator output determiner208ofFIG. 2determines an actuator setting from the virtual actuator setting in the selected feature record116-122(block718). The example actuator output comparator210determines whether the determined actuator setting is different than a most recent actuator setting (block720).

If the determined actuator setting is different than a most recent actuator setting (e.g., stored in the actuator output cache212ofFIG. 2) (block720), the example actuator signal generator214outputs the actuator control signal to control the actuator102according to the determined actuator setting (block722). In the door lock example discussed above, if the virtual actuator setting is lock, the example actuator signal generator214outputs a signal to cause the actuator102to physically lock the door.

After outputting the actuator control signal (block722), or if the determined actuator setting is the same as a most recent actuator setting (block720), control returns to block702to generate additional feature records116-122to continue control of the ubiquitous computing device100.

In some examples, blocks702and704are implemented in parallel with blocks706-722such that the feature controllers106-112generate feature records in parallel with the processing and coordination of the feature records and virtual actuator settings by the feature coordinator124.

FIG. 8is a flowchart representative of example machine readable instructions800which may be executed by the example feature coordinator124ofFIGS. 1 and/or 2to process a feature record. The example instructions800ofFIG. 8may be executed to implement the example block708ofFIG. 7. The instructions800are executed when the feature record manager202selects a feature record from a feature controller.

The example feature record manager202determines a feature, a priority value, and an actuator setting from the selected feature record116-122(block802). The feature and the priority value may be used to match the selected feature record116-122to a feature record116-122stored in the feature record cache114.

The feature record manager202determines whether the selected feature record116-122has the same feature and priority as a stored feature record116-122in the feature record cache114(block804). In other words, the feature record manager202determines whether the selected feature record116-122matches a feature record116-122stored in the feature record cache114. Whether or not the selected feature record116-122has the same feature and priority as a stored feature record116-122in the feature record cache114(block804), the example feature record manager202determines whether the actuator setting of the selected feature record116-122is dontCare (block806or block812).

When the input feature record116-122does not match any stored records (block804) and the actuator setting of the input feature record116-122is dontCare (block806), the example feature record manager202discards the input feature record116-122(block808). When the input feature record116-122does not match any stored records (block806) and the actuator setting of the input feature record116-122is an enumerated actuator setting (e.g., is not dontCare), the feature record manager202inserts the input feature record116-122into the feature record cache114in the order according to its priority and time (block810).

When the feature record manager202identifies a feature record116-122in the feature record cache114that matches the input feature record116-122(block804) and the input setting is dontCare (block812), the example feature record manager202deletes the matching feature record116-122from the feature record cache114(and does not replace it) (block814). As a result, the feature controller106-112that generated the input feature record116-122no longer has a feature record in the feature record cache114. When the feature record manager202identifies a feature record116-122in the feature record cache114that matches the input feature record116-122(block804) and the input setting is an enumerated actuator setting (e.g., is not dontCare) (block814), the feature record manager202deletes the matching feature record116-122and inserts the input feature record116-122into the feature record cache114in the order according to its priority and time (block816).

After processing the selected feature record (block808,810,814,816), the example instructions800end and return control to block710ofFIG. 7.

FIG. 9is a flowchart representative of example machine readable instructions900which may be executed by the example feature controllers106-112,300ofFIGS. 1 and/or 3to generate a feature record116-122. The example instructions900will be described below with reference to the example feature controller300ofFIG. 3.

The example sensor value reader302ofFIG. 3monitors sensors (block902). For example, the sensor value reader302determines whether sensor values have been received (e.g., via sensor data streams) from the physical sensors126,128, the virtual sensor models130-134, and/or the object state sensor136. If no sensor values have been received (block904), control returns to block902to continue monitoring the sensor(s)126-136.

When a sensor value is received (block904), the example actuator output determiner304determines an actuator setting (e.g., a virtual actuator setting) based on the behavioral requirement(s) of the feature controller300and the sensor values (block906). For example, the actuator output determiner304may use a state diagram such as the state diagrams400,410,420,430ofFIGS. 4A-4Dto determine the appropriate actuator setting.

The example feature record generator306ofFIG. 3determines a feature type, a priority value, and a mode setting from a feature configuration (block908). For example, the feature record generator306retrieves the feature type, the priority value, and the mode setting from the example feature configuration308ofFIG. 3. The example feature record generator306generates a feature record116-122including the determined actuator setting, the feature type, the priority value, and the mode setting (block910). In some examples, the generated feature record116-122further includes a time representative of the time the feature record generator306generates the feature record116-122.

The example feature record generator306transmits the generated feature record116-122to the feature coordinator124(block912). For example, the feature record generator306may transmit the generated feature record116-122via the toCoord data stream discussed above, from which the feature coordinator124may select and process the feature record116-122. The example instructions900return to block902to continue monitoring the sensors126-136for further sensor values.

FIG. 10is a block diagram of an example processor platform1000capable of executing the instructions ofFIGS. 7, 8, and/or9to implement the feature controllers106-112, the example feature coordinator124and/or, more generally, the ubiquitous computing device100ofFIGS. 1, 2, and/or3. The processor platform1000can be, for example, a server, a personal computer, a routing device, a network node, or any other type of computing device.

The processor platform1000of the illustrated example includes a processor1012. The processor1012of the illustrated example is hardware. For example, the processor1012can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

The processor1012of the illustrated example includes a local memory1013(e.g., a cache). The example processor1012ofFIG. 10executes the instructions ofFIGS. 7, 8, and/or9to implement the example feature controllers106-112, the example feature record cache114, the example feature coordinator124, the example sensors126,128, the example virtual sensor models130-134, the example object state sensor136, the example feature record manager202, the example feature record selector204, the example feature record pruner206, the example actuator output determiner208, the example actuator output comparator210, the example actuator output cache212, the example actuator signal generator214, the example sensor value reader302, the example actuator output determiner304, the example feature record generator306, and/or the example feature configuration308ofFIGS. 1, 2, and/or3.

The processor1012of the illustrated example is in communication with a main memory including a volatile memory1014and a non-volatile memory1016via a bus1018. The volatile memory1014may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory1016may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory1014,1016is controlled by a memory controller.

The processor platform1000of the illustrated example also includes an interface circuit1020. The interface circuit1020may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices1022are connected to the interface circuit1020. The example sensor(s)126-136ofFIG. 1are connected to the interface circuit1020. The input device(s)1022permit(s) a user to enter data and commands into the processor1012. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices1024are also connected to the interface circuit1020of the illustrated example. The example actuator(s)102ofFIG. 1are connected to the interface circuit1020to receive actuator output signals (e.g., from the processor1012). The output devices1024can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a light emitting diode (LED), a printer and/or speakers). The interface circuit1020of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The processor platform1000of the illustrated example also includes one or more mass storage devices1028for storing software and/or data. The example mass storage device1028implements the feature record cache114and/or stores the feature records116-122ofFIG. 1. Examples of such mass storage devices1028include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions1032ofFIGS. 7, 8, and/or9may be stored in the mass storage device1028, in the volatile memory1014, in the non-volatile memory1016, and/or on a removable tangible computer readable storage medium such as a CD or DVD.