Method and system for changing the behavior of a connected field device

Abstract

A method and a system for programming one or more behavior of a field device connected to a network comprising an input programming language to define the one or more behaviors to create an input program, transmitting over the network the input program to a translator coupled to the field device, translating the input program to generate a field program comprising a plurality of tasks and executing said field program by an executor coupled to said field device.

Claims

1. A computer-implemented method for programming one or more rules and associated tasks relating to one or more core functions of a field device executing an existing field program connected to a network comprising: receiving, on a memory of said field device, via said network, an input program, wherein the input program describes one or more behaviors intended to be executed by said field device; translating to modify the existing field program, by a processor on said field device coupled to said memory, a new field program defining the one or more rules and the associated tasks based on the input program, wherein said field device comprises one or more actuators and/or one or more sensors controlled using one or more core functions when the processor executes on one or more of said tasks; executing, by the processor located in said field device, said associated tasks in accordance with the one or more rules in place of said existing field program, wherein said processor schedules one or more tasks for execution at occurrence of a specific event based on one or more rules provided by said field program.

2. The method of claim 1 wherein said processor schedules one or more tasks for execution at a future time based on one or more rules provided by said field program.

3. The method of claim 1 wherein said processor schedules one or more tasks for execution at a set or recurring future time based on one or more rules provided by said field program.

4. A system for programming one or more rules and associated tasks relating to one or more core functions of a field device executing an existing field program connected to a network comprising: a processor located on said field device; a non-transitory memory coupled to said processor, the memory storing instructions that when executed by the processor, configure the system to: receive an input program via said network, wherein the input program describes one or more behaviors intended to be executed by said field device; translate to modify the existing field program, a new field program comprising said one or more rules and associated tasks, wherein said field device comprises one or more actuator and/or one or more sensor controlled using one or more core functions when the processor executes on one or more of said tasks; execute said associated tasks in accordance with the one or more rules in place of said existing field program, wherein said processor schedules one or more tasks for execution at a recurring future time based on one or more rules provided by said field program.

5. The system of claim 4 wherein said processor schedules one or more tasks for execution at a future time based on one or more rules provided by said field program.

6. The system of claim 4 wherein said processor schedules one or more tasks for execution at a recurring future time based on one or more rules provided by said field program.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

(1) To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

(2) FIG. 1 illustrates an application with field devices in communication with a terminal.

(3) FIG. 2 illustrates an application with field devices in communication with a terminal and a server.

(4) FIG. 3 illustrates an application with field devices in communication with a terminal and a server where the program is distributed.

(5) FIG. 4 illustrates a field device update method in accordance with one embodiment.

(6) FIG. 5 illustrates a field device update method in accordance with another embodiment.

DETAILED DESCRIPTION

(7) As per FIG. 4, certain capabilities within a field device 102 are inherent to the hardware on the field device 102 these are referred herein as the core functions 406. As an example, the way a device interacts with a sensor 110 or actuator 112 will not change throughout the lifetime of the IoT device because its dictated by the hardware itself. Given that these core functions 406 do not need to change, the embodiment focuses on creating a method to program the behavior of how such core functions should be used in a field device 102 to create the necessary functionality. There can be one or more core function 406 per sensor 110 and/or actuator 112 or one core function 406 can drive a plurality of sensors 110 and/or actuators 112.

(8) In a first embodiment, a developer 408 creates an input program 410 using a programming language. The input program is transmitted to a translator 402 on the field device 102 which converts the input program into a set and/or sequence of tasks to be performed or scheduled by an executor 404. The executor 404 executes the tasks, schedules tasks for execution or recurring execution. It may use memory 412 to store data and may communicate with the receiver and transmitter 414 of the field device to receive commands or transmit data.

(9) To keep with the temperature example, the software required to interface and read the temperature from a sensor is a typical core function 406. This function will not change throughout the lifetime of the IoT device and is considered as ‘static’ within the device. On the contrary, the frequency (aka sampling rate) at which the temperature is read and when should the temperature be read is dynamic and might change throughout the lifetime of the sensor. The programming language is used by the developer to define the ‘when’ and ‘at what rate’ should the temperature sensor be read on the field device 102. Other examples may be far more complex than this example but relate to programming how the device makes use of the core functions available.

(10) In this embodiment, when the field program 104 of the field device 102 needs to change, it can be achieved by simply sending a new input program 410 to the translator 402, which in turns generates the list of tasks or field program 104 to the executor 404 on the field device 102. The executor will replace its existing field program 104 with the new field program 104 and execute any new behavior defined by the tasks. The executor itself, however, does not have to change and neither will any other part of the field device's firmware, such as the core functions.

(11) Programming Language

(12) The programming language is designed such that it follows the paradigm known to the developer who is familiar with the cloud computing approach, thereby removing the need for this developer to acquire substantially new skills or pass the development on to professionals familiar with developing for field devices.

(13) The input program is sent to the field device, either through data exchange from a server or terminal over a network or via a local interaction with the field device. The programming language defines the behaviors of the field device 102 at a high level of abstraction and does not define the details of how the field device should execute the statements contained within the program. As a result, the program is small enough to be sent over a low bandwidth and power-deprived network.

(14) The programming language may be of a declarative nature, an imperative nature, or a blend of both. In case the input program 410 has a declarative nature, then the field program 104 may be of a purely declarative nature, an imperative nature or a blend of both. The programming language defines the behavior a field device 102 must accomplish rather than how to accomplish it.

(15) In one embodiment, the input programming language uses the semantics and syntax of declarative Structured Query Language (SQL). It can, for example, use a subset of SQL92, extended with special keywords and functions that facilitate the creation of logic and data streams on field device 102. As an alternative any declarative language can be used as a starting point or a new declarative language can be invented. The declarative language can be extended with keywords that map the elementary processes that a field device is capable of into the language.

(16) The input programming language is used to describe one or more behaviors intended to be executed by the field device 102.

(17) An example of input program 410 based on the above example is: Select avg(temperature) from sensors group by Date, DATEPART(mi, Date)/10 into network_message

(18) In this embodiment, the program language uses the programming paradigm known to the developer and hence makes it efficient for him to develop a program. There is no need for professionals specialized in embedded programming.

(19) Since the programming language, used in the embodiment described herein, does not deal with the core functions and the interaction with the hardware, the language is ‘abstracted’ from the hardware. This brings a new level of portability across different hardware (IoT devices). A program can work across different IoT devices, in the same network, as long as they all have the necessary hardware to support the intended operation.

(20) Translator

(21) The input program is transmitted to a translator that is invoked as soon as a new program arrives. The translator builds a set of tasks to be executed by the executor. The translator may finish as soon as the program is translated into tasks and then stops executing until a new program has arrived, or the translator may be invoked at various moments in time.

(22) The translator 402 typically resides on of the field device 102 and may include a pre-processor. The pre-processor can raise an alert to the developer in case of incompatibility between input program and field device capabilities.

(23) If a pre-processor is used, an example of pre-processed program 104 corresponding to the above input program:

(24) TABLE-US-00001   { ″type″:″select″, ″columns″:[{ ″type″:″function″ ″function″:″avg″, ″column″:″temperature″}], ″from″:″sensors″, ″groupby″:[{ ″type″:″Date″ ″part″:″Minutes″ ″divider″:10 }], ″into″:″network_message″}

(25) This pre-processed program is then translated into a field program. An example of a field program corresponding to the above example: Read_temperature(1 second, [accumulate(memory_location(A1)), increment(memory_location(A2)]) Timer(10 minutes,[average(A1,A2, A3), network message(A3)]

(26) The field program 104 is converted to binary to make it machine readable. The translated field program comprises a set of rules and associated tasks to be executed by the executor and the core functions 406.

(27) Note that the programming language and translated language is not limited to the above commands and syntax.

(28) The field program 104 may define how the field device 102 uses the sensors 110 and actuators 112 which are connected to it, how and when to interact with them. In another embodiment, the input program 410 contains additional behaviors to be performed by the field device 102 in addition to those behaviors already defined previously (the existing behaviors). In another embodiment, the input program 410 removes some existing behaviors to be performed by the field device 102.

(29) In another embodiment, the translator may implement a function to check the input program against the hardware and/or software capabilities of the targeted field device.

(30) In another embodiment, the pre-processor may implement a function to check the syntactic and/or semantic correctness of the input program.

(31) Executor

(32) The executor executes the tasks as generated by the translator. As a task can have a repetitive nature (e.g. sample temperature value every 1 minute), the executor runs continuously or intermittently, possibly with sleep periods between executing tasks. The executor will use the core functions to help executing the tasks. The executor can be considered in some cases as a scheduler that schedules tasks to be performed at a future time or schedule recurring tasks. The scheduler executes certain behaviors according to a statically (time based) or dynamically (event based) defined schedule. For example, measure temperature every second (static), calculate and send average every 10 minutes (static), measure humidity only when temperature is above 25 degrees (dynamic).

(33) The executor 404 may in addition to the hardware-related functions also execute generic computation functions, such as additions, multiplications, averaging, filtering, etc. In another embodiment, the executor may also allow to combine multiple functions into more complex functions.

(34) In this embodiment, the field program 104 defines how the field device 102 interacts with its environment 114 through their core functions 406, which data is exchanged with the terminal 106 or server 202 and which data transformations occur on the field device 102. The executor 404 does not contribute to any of these elements and is hence generic to any possible field program 104. This keep all the flexibility open to change the field device's behavior simply by changing the field program 104.

(35) In another embodiment, the input program 410 and/or field program 104 may implement machine learning and/or artificial intelligence algorithms.

(36) In another embodiment, the executor 404 may have built-in functions that execute machine learning and/or artificial intelligence algorithms.

(37) In another embodiment, the translator may run in a client-server environment

(38) In another embodiment, a security layer is added to ensure proper encryption and authentication of the input program 410 submitted to the translator.

(39) In another embodiment, an automation system manages a program update by using the capabilities of the translator to operate on the input program and subsequently manages the distribution of the output program to the field device 102.

(40) In the prior art, the field program 104 had to take care of the low-level hardware related operations of the field device 102 as well as describe in detail the operations performed on the data. In the embodiment described herein, the burden is shifted to the executor 404 and core functions 406. As a result, the size of the field program 104 is much smaller than the size of the program in the state of the art. The smaller program size makes a remote update much more feasible because it relaxes the need for high network capacity, it required less transmission energy and is costs less in transmission fee.

(41) When the field program 104 is updated, the executor 404 is not modified and neither does any other part of the field device's firmware. So a field program 104 update is performed without touching basic and core functions of the field device such as wireless communication and power management. This limits the risk of ‘bricking’ or ‘disconnecting’ the device in the field.

(42) Another advantage in comparison with the configuration approach of the state-of-the art is that the functionality in terms of processing and generated output data flow is not constrained by a predefined configuration structure and can encompass all the functionalities that are possibly supported by the field device's hardware.

(43) In another embodiment, as shown in FIG. 5, optionally the invention may add a pre-processor 510 between the developer and the field device, as depicted below.

(44) In this embodiment the pre-processor 510 is located outside of the translator and the field device. It receives the input program from the developer. The pre-processor 510 then executes certain checks and transformations on the program, yielding the pre-processed program 512. The pre-processed program is further fed to the field device and continues to be processed in the same way as in the main embodiment. The pre-processor can, for example, carry out one or more of the following functions: Compress the program to generate a smaller data size, with the advantage of improving the efficiency in transmission, especially useful when sending over a low bandwidth and power-deprived network. Check the input program against the hardware and/or software capabilities of the targeted field device. The pre-processor may raise an alert to the developer in case of incompatibility between input program and field device capabilities. Check the syntactic and/or semantic correctness of the program.