GB2540394A

GB2540394A - Remote configuration of devices

Info

Publication number: GB2540394A
Application number: GB1512384.7A
Authority: GB
Inventors: John Martin Vincent Hugo; Crosby James; Chang Marcus
Original assignee: Arm IP Ltd
Current assignee: Arm IP Ltd
Priority date: 2015-07-15
Filing date: 2015-07-15
Publication date: 2017-01-18
Also published as: GB201512384D0

Abstract

Disclosed is a system for changing or assessing the performance of node devices. A first device in communication with the node devices, sends to a node device predicates specifying a test to be made by the node device on its operational state and the node sends the resulting test data back to the first device. Also disclosed, is a system in which a first device sends data to nodes specifying conditions to be fulfilled in the node or the environment, the node testing for the conditions and sending back specified data when the conditions are fulfilled. Also disclosed is a method of debugging a node device by sending a predicate that defines a state to be tested, the device then sending back test results. Also disclosed is a method of debugging a node following a trigger event, in which the content of a memory stack is recorded, and a predicate causes the node to check the memory stack for similar content, and to generate a warning if similar content occurs.

Description

Remote Configuration of devices

The present technology relates to systems and methods for remote configuration of electronic devices.

Embodiments can be used in setting up, operating and updating bandwidth-constrained devices. This may apply to programmable computers or processors in many applications; one field of application is to embedded devices, i.e. devices with built-in processors for their control. Such devices could be mobile phones, watches, washing machines, crop sprayers or almost any electronic device or apparatus with electronic control. If, as is increasingly the case, a wireless communication facility with other devices, or with the Internet, is built in, the devices can become part of the so-called the Internet of Things (IoT). The IoT enables communication between devices, automation, location, remote monitoring and control and many other applications.

Although such devices usually communicate wirelessly and have some form of processor, they may have constrained storage, nor can they handle a large bandwidth of data.

Hence any updating that needs to be carried out is constrained. Moreover, the processors are usually difficult to program once they are installed. However, often the software or firmware needs to be updated. Though software updates over the Internet are common enough, the updating of IoT devices is not so easy, partly because of the small memory and processing capacity of the devices, but also because of the fact that they are often battery-powered, whereas updating operating systems, and transferring large quantities of data, are power-hungry operations.

The present disclosure in one aspect provides a method of communication between a first device, e.g. central processor or controller, and a node device, usually a computer such as an embedded device, in which the controller sends data to the device, the data including a predicate defining whether a given condition is fulfilled. Also discussed is a central processor configured to generate predicates for sending to such devices, and a node device (computer or embedded device, for instance) having such a predicate.

Accordingly, techniques may provide a system for influencing or assessing the performance of one or more node devices, including a first device in communication with at least one of the node devices; wherein the at least one node devices is configured to receive from the first device predicates specifying a test to be made by the node device on its operational state and to send the resulting test data to the first device. Operational state may be taken to mean, alone or in combination, the operation, the state or the surroundings of the node device.

For present purposes a predicate is taken to be a small piece of code which, unlike software updates, can be updated separately to the rest of the system, and without interrupting the operation of the rest of the system (i.e. it is not necessary to reset or restart any application code to update a predicate, as the predicate has no state of its own that needs clearing when it is updated). Typically the predicate or predicates will make up less than 0.01%, or even less than 0.001%, of the total code in the operating system of the computer or embedded device. It will define a condition that may be fulfilled or not (i.e. is True or False, in Boolean terms) when tested by the device. Their function is, for instance, to cause data to be logged, and to examine the state of the application or of the computer. In many embodiments they cause data to be stored locally for transmission at a later time. They can be made up of compiled native code.

By "central processor" or "controller" is meant any local or distributed computing facility that communicates with remote or embedded or "node" devices to oversee their function. Such a facility is also known as a "first device" herein.

Predicates can also be used when a report has to be sent from the embedded device to the central processor: it is cheaper in terms of power consumption to process as much as possible within the remote computer or embedded device, to minimise the amount of data that needs to be transferred.

One occasion when large amounts of data need to be sent is when a malfunction has occurred and the computer needs to be debugged.

In a second aspect there is provided a method of testing or debugging a node device (e.g. computer or embedded device), in which a predicate is sent from a first device (central processor) to the node device, the predicate being configured to initiate and/or define a debug program in the device. The debug program may, for instance, ascertain the content of certain memory registers in the device before a crash or reboot, and send the content, or a processed form of the content, to the central processor for analysis.

Once the predicate is installed in a device and an error or predetermined event occurs, a sequence of events is initiated, as determined by the predicate; the device can be commanded to send the data, or buffer it for sending later, or to analyse the data and send it with an answer back to the central processor (or store the answer for sending later).

In general, for embedded devices and the like, it is cheaper to perform computation locally - for instance, to determine what kind of error has occurred - than to send large quantities of data for analysis remotely.

One of the functions of the operating system of an embedded device with wireless capability is to switch the radio on and off.

It may be advantageous to apply the predicate idea to a raft of users or devices, such as all the users of a given model of mobile phone, all enabled to use such predicates.

For instance, the predicate can be sent to certain users, but not others, or a different predicate is sent to others, and data sent back from the devices to the central processor can be compared. The predicate could include a flag specific to a user or developer, say of an application, so that an error notification goes to the originator of a section of code. A further option where there is a base of users is to distribute the logging process among them, so that the drain on battery life entailed by the call on the individual device to send data is spread amongst the users. This can be done at random, where each user/device is called upon for a stretch of time at a random point over the measurement period, or systematically, following a rota or at regular intervals .

The devices of interest can be low-power devices, and may be battery-powered; one application would be sensors in the field or in a building. The events looked for could be crashes or other failures or bugs; they need not be negative, but debugging is expected to be an important application of embodiments of the idea. A function of the control system could be to group error reports by similarity, so that reports emanating from devices belonging to or supported by a single developer can be reported to that developer. Parameters such as location and sensor value can be included in order to assist the search for the causes of systematic errors.

Because many parties are involved, privacy issues may arise. The system allows the filtering out of private information from the reports. For this, the device can include an extra piece of code - this code will be more or less fixed, unlike the predicate. The application itself should preferably define the filter.

Embodiments of the invention make particular use of object-oriented programming, using a suitable language such as Objective C.

For a better understanding of the invention, examples will now be described by way of example, referring to the attached drawings, in which:

Figure 1 schematically shows a system overview showing an embodiment, including embedded devices and a control unit;

Figure 2 shows an embodiment in which different predicates are used at different times for different devices; and

Figure 3 schematically illustrates a relevant part of the operating system of a device, including a list of predicates stored on the device.

In Figure 1 a system is shown comprising a central controller 1 (the term "central" is used for convenience: the item could itself be distributed, but it has the function of control of a large number of devices and generally has a large processing capacity). In this embodiment it includes a log data service 3, a predicate builder 5 and an automatic predicate generator 7 in case it is desired to have predicates generated and sent out other than manually by the developer/debugger.

The controller 1 is in communication, e.g. by way of the Cloud, i.e. using servers on a remote network, with various computers in the form of embedded devices 20 containing software, including an operating system or OS. The operating system as a whole is not easy to alter from outside, but a small part of it can in effect be altered by the controller sending data influencing the operating system, known as a "predicate", to the remote device. The predicates are, relative to the operating system, easy to change and update because: they are small pieces of code that can be separately and remotely updated; updating them does not require the reset or restart of any OS or application components; and they do not interfere with the operation of the OS or of the application, so they can be updated without having to be able to revert back to a previous state in the case of an unexpected error: if a predicate misbehaves it could simply be automatically disabled, with no consequence to the operation of the device.

The predicate could be binary code or a function, for instance, and represents a condition to be tested by the operating system (OS). If the condition returns True, or otherwise indicates a match, the OS carries out a corresponding action. This action could be defined in the OS itself, such as to increment a counter, or it could be received paired with the predicate.

Typically the OS has a scheduler which decides when each unit of application or OS code should be executed. Here it also looks for predicates in a list. The list could be hierarchical, with a priority ranking for a plurality of predicates, and the testing of individual predicates can vary widely: typically, critical conditions could be tested at a frequency of the order of 1 MHz, while some other checks could be carried out once a day. An example of the latter would be checking battery usage over the preceding day; if the usage is greater than usual, and/or greater than a certain amount as specified in the predicate, the OS sends a message back to the server. Such usage could indicate a security violation, for instance. The checks can be regular, or randomly at an average frequency.

The scheduler may itself be responsible for evaluating predicates, when it is switching between different units of application code, but the evaluation of predicates may instead be carried out by an evaluation engine external to the scheduler and called by the latter at appropriate times. A predicate does not need to represent only a single condition or test: it can include a set of such conditions. A reason for more complex predicates is to eliminate or reduce false positives, which are a drain on resources. However, because even a complex predicate is still a very small amount of data to be transmitted, embodiments of this kind still greatly reduce the amount of data to be transferred. In effect, the use of predicates in the computer or embedded device enable trace data to be identified in the device, and then exported back to the server, rather than sending all the data from the device, for the trace to be identified in the server.

Another use of a predicate in an embedded device is to signal a particular event. As an example, the predicate could specify a test for the size of the routing table that the device requires in a mesh network - for instance, a maximum tolerable size could be specified, and a maximum number of hops through the mesh. If the device detects that these parameters are exceeded, a signal is sent to the controller/server and suitable action taken. Similarly, instantaneous or cumulative power consumption can be monitored.

In a simple configuration, developers A, B write software and apps for the remote devices. If for instance the controller/developer A of the operating system, or a third-party developer B, wishes to update software in the devices, software updates or predicates are sent to the central controller 1 as at 21. Note that, for clarity, not all possible arrows indicating transfer of data are shown in Figure 1. The predicate builder 5 generates predicates according to the required function, and these are sent to the devices 20 as at 23. For an update, the device then installs the functions in accordance with the information in the predicate. For debugging, the operating system uses the directions in the predicate to trace stack errors, radio use and other parameters, which are sent back to the controller 1, and specifically to the log data service 3, as seen at 25.

More generally, A is the app developer, the OS is developed by C, the originator of the system, and used by A. Code developed by B may also be used by A, and code developed by some other party D may be used by the originator in the operating system.

As also visible in Figure 1, there is an option for the controller to send predicates automatically, as at 23a, using the automatic predicate generator 7. Following a specified event, such as a reboot, or an incident of a threshold of radio use being exceeded, log data 25 are sent from the remote device 20 to the log data service 3. This can happen immediately or, if conditions are inexpedient, the data can be stored and sent later, or, further preferably, the data can be processed in situ using the device's own processor and the predicate information, to generate the required error information, which is then sent to the controller 1. The log data service 3 sends the analysed information back to the developer 1, as shown at 27.

Figure 2 shows how a system can be designed to track radio use in a remote device, in fact a large set of remote devices, in this example cellphones, distributed among users. The predicate sent to and incorporated in the device effectively instructs the device to log when the radio is turned on and off, along with specified status information about the device or its environment. One predicate, PI, is sent to one set of embedded devices 20, at the same time or at different times tl, t2, t3, while another predicate P2 is sent to other devices, nominally labelled 20a, though there is no difference in principle between these and the first set 20. Indeed, the different predicates may be sent sequentially to the same subset of devices or to all devices. At intervals - for instance when a buffer continuing the log information is full - the devices send the log information to the server.

The radio usage of the devices is then compared, in conjunction with the information about the specified status information, which may be, for example, the contents of certain memory registers, or a point when a particular function is called, for instance for debugging purposes.

Since the selection and/or analysis of the data collected is performed, at least in part, in the embedded device, the amount of data to be transmitted back to the server is greatly reduced.

In this way the operating system can be optimised, or new operating systems tested in the field, or debugging procedures carried out, with minimal demands on memory and bandwidth capacity. Figure 3 illustrates the salient parts of an embedded device 20, having an operating system, or the core of it, schematically denoted 200, memory in the form of a stack 202, possibly as RAM, and a scheduler 204, itself in the form of a stack or priority list of functions or operations. A radio input/output unit 210 is controlled by the operating system to communicate with the controller 1.

When the controller 1 sends a predicate to the embedded device 20, the operating system writes the corresponding function to the scheduler 204, with the specified priority level and frequency. During operation, the OS checks the scheduler; when the predicate returns a True result, the corresponding data are retrieved, which may be data from the stack 202. The data are then sent to the controller 1 for analysis .

Claims

1. A system for influencing or assessing the performance of one or more node devices, including a first device in communication with at least one of the node devices; wherein the at least one node device is configured to receive from the first device predicates specifying a test to be made by the node device on its operational state and to send the resulting test data to the first device .

2. A system according to claim 1, in which the test includes determining the instantaneous or cumulative power consumption of the node device.

3. A system according to claim 1 or 2, in which the node device includes a wireless communication unit and the test includes determining the usage of the wireless communication unit.

4. A system according to any preceding claim, in which the test is configured to ascertain a configuration of data stored in the node device.

5. A system according to any preceding claim, in which the said configuration of data includes the contents of particular memory registers.

6. A system according to any preceding claim, in which the said configuration of data includes data describing radio use of the node device.

7. A system according to any preceding claim, in which the said configuration of data includes data recorded by sensors in the node device.

8. A system for communication between a first device and a remote or node device, the first device being configured to send data to the node device, specifying one or more conditions to be fulfilled in the node device or in its environment, and the node device is configured to test for the conditions and, when it is or they are fulfilled, to send specified data back to the controller.

9. A system according to any preceding claim, further including a plurality of node devices.

10. A system according to claim 6, in which at least some of the node devices are identical to each other.

11. A system according to any preceding claim, in which the node devices are embedded devices each containing a computer .

12. A node device having a processor including an operating system, and a transmitter/receiver for communication at least with a first device, the operating system including a part for storing predicates sent to it by the first device, the predicates defining a test to be carried out in the node device and resulting data to be sent back to the first device.

13. A node device according to claim 12, the operating system including a scheduler, or schedulers, determining when the predicates are evaluated.

14. A method of testing or debugging a node device having an operating system, in which a predicate is sent from a first device to the computer, the predicate being configured to define a state of the node device to be tested, and to cause the operating system to send corresponding test results back to the first device.

15. A method according to claim 14, in which the test ascertains the content of certain memory registers in the node device before an error, and the operating system sends them to the first device for analysis, or analyses them and sends the result to the first device.

16. A method according to claim 14, in which the test ascertains data relating to radio usage by a transmitting/receiving unit of the node device, and the operating system sends the data to the first device for analysis .

17. A method according to any of claims 14 to 16, in which there are several node devices and the same or different predicates are sent to different node devices and the test results are compared.

18. A first device configured to carry out any or all of the methods of claims 14 to 17.

19. A first device according to claim 18, containing a log data service and a predicate builder for generating predicates according to input from a developer.

20. A system, method or first device according to any preceding claim, in which the node devices include one or more of the following: mobile telephones, laptop computers, netbooks, tablets, other personal computing devices, sensors, vehicle equipment.

21. A method according to any of claims 14 to 17, in which private data are first filtered out of the logs sent to the developer.

22. A method of debugging a program in a node device following a trigger event, in which the content of a memory stack in the node device after the trigger event is recorded, and a predicate is included in the node device that causes the operating system of the node device or of other node device s to check the memory stack during subsequent operation for a similar content of the memory stack, and to generate a warning if a similar content occurs, so as to give advance warning of a possible repeat of the trigger event.

23. A method according to claim 22, in which the trigger event is a system crash.

24. A method according to claim 22 or 23, in which the process is iterated.