Technical field The technology disclosed herein relates generally to the field of operations support systems, and in particular to method for autonomous operation and maintenance of a sensor network, sensor management system, computer programs and computer program products.

Background Internet of things (IoT) may encompass a variety of "things" and applications. An example is a network comprising sensors and other devices gathering data. Such sensor network may be deployed over geographically large, outdoor environments, e.g. fields, forests, seas and lakes, etc. This particular deployment is challenging e.g. due to the size of the area where the sensors are deployed. In such rural

environments it may for instance be difficult to locate individual sensors, and it may be difficult for maintenance personnel to access all parts of the area in a timely fashion. This may result in costs caused from significant delays or malfunctions in systems or applications that are dependent on the sensors due to the unavailability of retrieving data from faulty sensors. The size of the deployment area also renders an actual replacement of faulty sensors difficult. Further still, in the large-area deployment it may be difficult to establish the reason(s) for any malfunctioning.

Summary

An objective of the present disclosure is to solve or at least alleviate at least one of the above mentioned problems. The objective is according to an aspect achieved by a method for autonomous operation and maintenance of a sensor network. The method is executed in one or more nodes of a sensor management system. The method comprises establishing one or more requirements for each of one or more sensors; executing an automated installation process, comprising: obtaining information about each of the requested one or more sensors, the information identifying type of sensor and an intended deployment location thereof, acquiring, based on the obtained information, the one or more sensors, configuring sensor software of each of the one or more sensors, and deploying the one or more sensors at their respective deployment location.

The method enables an increase in the level of automation in sensor network logistics operations, i.e. supply chain, both during initial network deployment as well as during operation of the network. The increased level of automation in turn provides lower operational costs, in terms of money as well as time, for operators of sensor networks. Further, the sensor network is also rendered more reliable in view of network deployment and maintenance, e.g. by removing dependency on human skill and automated fault-detection.

The objective is according to an aspect achieved by a computer program for managing a sensor network. The computer program comprises computer program code, which, when executed on at least one processor in a sensor management system causes the sensor management system to perform the method as above The objective is according to an aspect achieved by a computer program product comprising a computer program as above and a computer readable means on which the computer program is stored.

The objective is according to an aspect achieved by a sensor management system for autonomous operation and maintenance of a sensor network. The sensor

management system comprises one or more nodes configured to: establish one or more requirements for each of one or more sensors; execute an automated

installation process, comprising to: obtain information about each of the requested one or more sensors, the information identifying type of sensor and an intended deployment location thereof, acquire, based on the obtained information, the one or more sensors, configure sensor software of each of the one or more sensors, and deploy the one or more sensors at their respective deployment location.

Further features and advantages of the present disclosure will become clear upon reading the following description and the accompanying drawings.

Brief description of the drawings Figure 1 illustrates schematically an environment in which embodiments of the present teachings may be implemented.

Figure 2 illustrates a flow chart for detecting a sensor error in accordance with an aspect of the present teachings. Figure 3 illustrates a flow chart for detecting a link related error in accordance with an aspect of the present teachings.

Figure 4 illustrates a flow chart for detecting measurement errors in accordance with an aspect of the present teachings.

Figure 5 illustrates a flow chart of a method in accordance with the present teachings. Figure 6 illustrates schematically a sensor management system and means for implementing methods of the present disclosure.

Figure 7 illustrates a sensor management system comprising function

modules/ software modules for implementing methods of the present disclosure.

Detailed description In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.

Briefly, the present teachings provides, in various aspects, methods and a system for automating the supply sensor for sensor network support operations during the network lifecycle, i.e. from initial deployment to subsequent maintenance and decommissioning. Automation of management of sensor networks, in particular deployment, operation and decommissioning is known, but the inventors of the present invention have realized a need to address the fact that human involvement is required for supplying new sensors for deploying the network initially and/ or replacing faulty sensors. Sensor supply chain, e.g. ordering, manufacturing and supplying the sensor to the sensor network operator, as well as actions affecting sensor hardware, required as a result of monitoring during sensor lifecycle management are still assumed to be human operations. As indicated in the

background section, this human-in-the-loop factor adds cost and time delay when deploying/ maintaining sensor networks. In various aspects, the present teachings suggests definition of interfaces and usage of existing protocols, such as Simple Network Management Protocol (SNMP), in order to describe an interaction among nodes in order to achieve the initial deployment or replacement of a sensor, in a full machine-to-machine communication approach that eliminates the need for human interaction. In an aspect, the present teachings suggests a "sensor generations" concept, which may be seen as an evolution of sensor hardware, under which a sensor management system learns about the cause of a sensor malfunction and improves the sensor replacement in order to deal with the error.

Figure 1 illustrates schematically an environment in which embodiments of the present teachings may be implemented. The environment is in the following denoted sensor management system 1, wherein data may be communicated between various devices in an autonomous manner. For instance, a sensor reporting a fault may autonomously trigger the initiation of a procedure for replacing the sensor, which procedure in turn is performed autonomously without any human involvement. The sensor management system 1 handles, e.g. manages, a sensor network 2 comprising one or more sensors SI, S2,.., Si,.., Sn. The sensors SI, S2,.., Si,.., Sn may be devices that measure one or more values from their environment, e.g.

temperature, luminosity, humidity, wind, rainfall, presence, barometric pressure, etc. and transmit those values to a sensor management node 3. Each sensor SI, S2,.., Si,.., Sn in the sensor network 2 may either transmit information to the sensor management node 3 proactively, e.g. periodically or whenever it has information available, or reactively, when requested from the sensor management node 3.

Depending on the nature of the sensor network 2, each sensor SI, S2,.., Si,.., Sn may send the data to the sensor management node 3 directly, e.g. via Global System for Mobile Communications (GSM) or other 2G technology, 3G or Long Term Evolution (LTE) radio transceiver, or use other sensors in the sensor network 2 to relay the data until this data reaches the sensor management node 3. Examples of the latter comprise e.g. a mesh network topology using low cost, low power radios based e.g. on IPv6 over Low power Wireless Personal Area Networks (6LowPAN) protocol stacks. It is noted that the protocol for data transmission can be wireless or wired.

The sensor management node 3 may comprise or be connected to a sensor database 4, which may comprise a registry of the sensors SI, S2,.., Si,.., Sn deployed in the sensor network 2. For every sensor SI, S2,.., Si,.., Sn, information such as e.g. its type, a unique identifier and its location, e.g. geographical coordinates, may be stored in the sensor database 4. The sensor management node 3 may be arranged to handle a number of tasks, for example arranged to: - Bootstrap the sensor network 2 by registering new sensors in the sensor database 4 and mediating for the automated creation and deployment of these sensors

(described more in detail later).

- Monitor the current status of the sensor network 2 during its operation, detect faulty sensors and mediate an automated process of replacing these faulty sensors. The sensor management node 3 may further register new sensors added after the sensor network 2 bootstrapping. For instance, new sensors may be added in an upgrade operation or expansion operation, e.g. to cover a new area, and such sensors may be registered.

There are various ways for the sensor management node 3 to detect faults in one or more sensors SI, S2,.., Si,.., Sn in the sensor network 2. For instance, a fault may be detected by the fact that the sensor management node 3 is not receiving data from sensors, is receiving erroneous data from sensors, and is receiving error codes from sensors. These three examples are described more in detail in the following.

If the sensor management node 3 is not receiving data as expected it may for instance be due to that a sensor or group of sensors are not transmitting data (e.g. a value), or that the sensor(s) are not responding to a request after a specific time interval has elapsed. This may indicate a sensor malfunction, e.g. out of battery, or over the air (OTA) connection malfunction.

A fault may be detected or at least suspected if the sensor management node 3 is receiving erroneous data, or what seems to be erroneous data, from a sensor or group of sensors. The fact that a sensor is transmitting an erroneous value may for example be detected if it transmits an alphanumeric value instead of an expected integer value or a value out of range, e.g. 1000 degrees Celsius.

A fault may also be detected by the sensor or group of sensors explicitly transmitting an error code. In such a case the error may typically be directly traced to a specific error by relating it to the corresponding sensor specifications.

Based on the above, a number of different types of faults may be attributed to the sensors SI, S2,.., Si,.., Sn, for instance:

• Battery Error - Depleted Battery · Radio link error

• Erroneous Measurement Reading

The sensor management system 1 may comprise a sensor maintenance node 5, which may be arranged to order a new sensor from the sensor management node 3 and keep track of the sensor manufacturing and deployment/ installation process. In addition, sensor maintenance node 5 may be arranged to make recommendations for improvement of a particular sensor based on the fault detected by the sensor management node 3 and reported to the sensor maintenance node 5. For example, the sensor maintenance node 5 may recommend the usage of a larger battery in case the battery of the previous sensor was depleted very rapidly (or a smaller one in the opposite scenario), or another type of battery.

The sensor maintenance node 5 may comprise, or have access to, a blueprint database 6 comprising blueprints on e.g. the sensors. Each blueprint may comprise a set of instructions relating to the sensors, which may be provided to the sensor manufacturer. It is noted that, although illustrated in figure 1 as separate nodes, the sensor management node 3 and sensor maintenance node 5 are logically rather than physically distinguished, which means that both these nodes 3, 5 could reside in a single device, for example in a gateway. The sensor management system 1 may correspondingly comprise one or several nodes. A sensor manufacturer 7 is responsible for manufacturing the sensor SI, S2,.., Si,.., Sn. The sensor manufacturer 7 may manufacture the sensors on order from the sensor maintenance node 5 and out of a sensor blueprints, e.g. obtained from the sensor maintenance node 5. The sensor manufacturer 7 may subsequently notify the sensor maintenance node 5 when the manufacturing process is completed. The sensor manufacturer 7 may for instance involve Computer Numerical Control (CNC)- enabled machines and/ or 3D printing equipment in order to design and manufacture the sensors. The sensor manufacturer 7 is typically not part of the sensor

management system 1, although it could, in some embodiments, be a part thereof. The sensor management system 1 may be configured to use a sensor deployment service 8, which is responsible for picking up the sensor SI, S2,.., Si,.., Sn from the sensor manufacturer 7 and dropping it to its intended location in the sensor network 2. The sensor deployment service 8 may involve land-based and/ or airborne unmanned vehicles, e.g. robots, drones. The sensor deployment service 8 may be completely autonomous with means of delivering the sensor SI, S2,.., Si,.., Sn to its intended location, or a semi-automated system that may require human intervention at some point during the delivery process. Like the sensor manufacturer 7, the sensor deployment service 8 is typically also not part of the sensor management system 1, although it could, in some embodiments, be a part thereof. The below table illustrates an exemplary sensor sheet comprising information about a sensor, e.g. the capabilities thereof.

Model "CT-027F" Model of the sensor as defined by its

manufacturer

Range -20°C to 45°C Range of the sensor in Celsius for this particular model

Drift 0,002°C /day Drift - describes the sensor's loss of accuracy over time

Resolution Step size 0.125°C Describes the smallest change in the observed amount (step) that can be detected by the sensor

Such information, and other types of information, may be stored in the sensor management node 3 and/ or the sensor database 4, which may but need not be part of the sensor management node 3.

The present teachings may, in an aspect, be seen as comprising two distinct phases. Phase 1 focuses on determining that an error has occurred in the sensor network 2 deployment while Phase 2 focuses on generating a recommendation regarding the replacement of the sensor from which the error originates.

For Phase 1 the following three exemplary categories of errors are considered in the following: battery error (figure 2), radio/link error (figure 3) and erroneous reading/ measurement (figure 4). It is noted that these types of errors are merely provided as a set of examples and that the present teachings should not be construed as being limited to these.

Figure 2 thus illustrates a flow chart for detecting a sensor error in accordance with an aspect of the present teachings, in particular a first category of sensor error:

Battery error. A battery error can be detected in different ways, the simplest being when the sensor itself transmits this information using a particular error code.

Another way of detecting a battery error may be to establish that no

reading/ measurement has been received from a sensor even though such

reading/ measurement was expected. The sensor management node 3 may for instance comprise information on that it should receive a reading from a certain sensor at a particular time instance, since the sensor is programmed to broadcast information at periodic intervals. Hence, if no such reading is received, the sensor management node 3 may suspect that a battery failure has occurred. The sensor management node 3 may, for instance, monitor the battery status, e.g. battery charge level, of a sensor. Such monitoring may be performed over time and the

corresponding information be registered. The sensor management node 3 may then check the current battery status and compare it to an expected battery status for this particular type of battery. Based on this, the sensor management node 3 may establish whether or not the sensor has experience a battery failure. A typical behavior of a battery is that the current level decreases linearly over time, and based on this the sensor management node 3 may establish whether any battery fault is an expected battery failure or unexpected battery failure.

The flowchart of figure 2 describes a process 20 comprising steps taken according to an embodiment, in order to decide what kind of recommendation to make in the case that a battery error has been detected. The process may for instance be executed by the sensor maintenance node 5.

In a first step, box 21, in this process 20 sensor information is retrieved (or received) from the sensor management node 3. In this step sensor information such as e.g. the model of the sensor and its location may be of interest. In decision box 22 the sensor maintenance node 5 checks if this particular failure was expected, e.g. from a time/ date perspective, or not. This may be done by checking a repair reliability database (box 26), which records different failure incidents but also contains information about the expected lifetime of the different sensors and their corresponding batteries. If the type of fault ("faultType= expectedBatteryFailure" in figure 2) is an expected failure then flow continues to box 26, wherein the failure incident is recorded in the repair reliability database, for instance entering

information on date, model and type of fault. Flow then continues to box 27, wherein the sensor maintenance node 5 may, since the fault is an expected one, recommend the previously used battery as a replacement. If, in box 22, the failure is an unexpected failure ("faultType=

UnexpectedBatteryFailure" in figure 2), flow instead continues to box 23, wherein the repair reliability database is again updated by recoding the incident, for instance entering information on date, model and type of fault.

Next, in boxes 24 and 25, an iteration over a list of possible alternatives is made in order to find one alternative that is a suitable replacement. In box 24 another sensor model than the failed one is selected and in box 25 it is checked if this selected sensor is compatible with the failed battery model. A selected sensor may for instance be compatible with the failed battery model if having similar precision, similar drift and/ or mean time before failure, etc. For the selected sensor to be compatible with the failed sensor it has to fulfil at least some basic requirement, e.g. a temperature sensor should obviously be required to be able to measure temperature, and preferably the list contains only such alternatives. As still another example on a criterion for the sensor to be compatible with another one is that the connection (interface) of the sensor to its sensor board should be the same: both the selected sensor and the failed sensor should comply e.g. to serial peripheral interface (SPI). If not compatible, flow returns to box 24, wherein yet another sensor model is selected. If yes, i.e. if the sensor model is found to be compatible, then flow continues to box 27, wherein the sensor management node 5 may recommend this sensor model.

This particular approach is advantageous in that it covers both the case where the battery of the sensor has malfunctioned prior to it's expected date and also the case where the battery of the sensor has malfunctioned after it's expected date. In another embodiment, the flowchart of figure 2 can be refined in order to e.g. select more powerful batteries in case the battery that's being replaced is malfunctioning too often in the field. Figure 3 illustrates a flow chart for detecting a link related error in accordance with an aspect of the present teachings, in particular a second category of sensor error: link error. The link may comprise a radio link or a wired link. A link error occurs when no information has been received from a sensor even though information was supposed to be received, e.g. due to a periodic scheduling of the sensor's broadcasts or the information that was received cannot be read because its content is malformed.

The flowchart of figure 3 describes a process 30 comprising steps taken according to an embodiment, in order to decide what kind of recommendation to make in the case a link error has been detected. The process 30 may for instance be executed by the sensor maintenance node 5. In a first step, box 31, of the process 30, sensor information is retrieved (or received) from the sensor management node 3. In this step sensor information such as e.g. the model of the sensor and its location may be of interest.

An interesting corner case that may be dealt with is that of weather conditions, box 32. It is known that micro-wave links can be affected by rain, and an important check condition in the process 30, illustrated at box 32, may therefore be to check for such conditions. In particular, if it is established that extreme weather conditions persists, it may be checked (box 33) if nearby sensors suffer from similar problems. If nearby sensors indeed suffer from similar link problems ("Yes, fault replicates" in figure 3), flow continues to box 34, wherein the anomaly is registered and the process 30 is ended. If in box 33, it is established that the sensor is the only one (or one of few) that is having link problems, i.e. the link error is likely not due to the weather conditions ("No, radio transceiver fault" in figure 3), then flow continues to box 35.

In box 35 the incident may be registered and a recommendation may be to e.g. choose a different antenna technology. A different antenna technology may be selected for the wireless link, for example Global System for Mobile Communications (GSM) if Bluetooth fails, WiFi or visible light communication (VLC) if Bluetooth fails, etc., in any combinations. An iteration over a list of possible alternatives is made in order to find one alternative that is a suitable replacement. Another antenna technology than the failed one is selected and in box 36 it is checked if this selected sensor is compatible, in a manner similar to the battery compatibility check described with reference to figure 2. If not compatible, flow returns to box 35, wherein yet another antenna technology is selected. If yes, i.e. if the antenna technology is found compatible, then flow continues to box 37, wherein the sensor management node 5 may recommend this antenna technology for use in the future for this sensor. If, in box 32, it is established that the weather conditions are not such, that a link failure may be suspected to be due to the weather, then flow 30 continues directly to box 35. External weather services and/ or applications may be relied upon for establishing the weather conditions, and based on this and prior knowledge about under what type of weather conditions a certain sensor might fail, conclusions can be drawn about the failure.

Figure 4 illustrates a flow chart for detecting measurement errors in accordance with an aspect of the present teachings, in particular a third category of sensor error:

erroneous reading/measurement.

The flowchart of figure 4 describes a process 40 comprising steps taken according to an embodiment, in order to decide what kind of recommendation to be made in the case an erroneous measurement has been received. The process 40 may for instance be executed by the sensor maintenance node 5.

In a first step, box 41, in the process 40, sensor information is retrieved (or received) from the sensor management node 3. In this step sensor information such as e.g. the model of the sensor and its location may be of interest as well as obtained

measurement(s).

In box 42, an erroneous measurement/reading is detected. The erroneous

measurement/reading may be established when a sensor reports a measurement that can be read correctly, and therefore there are no radio/ link errors, but the

measurement is incorrect, i.e. a measurement is reported that is beyond the readings (outside a range) that the sensor can actually make or a measurement is made that is inappropriate in a particular context. The measurement is an outlier measurement if it is distant from other measurements.

The flowchart of figure 4 is similar to the ones presented for the previous categories of errors. If in box 42, it is determined that the measurement is not an outlier measurement (arrow indicated "No"), then flow continues to box 43, wherein the context is checked. For instance, it may be established that a measurement is incorrect in a context e.g. when a speedometer reports that a runner is moving at 3*10 ⁸ m/ s. The measurement is then an unrealistic measurement, i.e. out of context, and the flow continues to box 44, wherein a repair reliability database is updated. Such update may for instance comprise information such as date, model and type of fault as indicated in the figure.

If in box 42, it is determined that the measurement is an outlier measurement (arrow indicated "Yes"), then the repair reliability database may again be updated (box 44), with corresponding information.

From box 44 flow continues to boxes 45 and 46, wherein an iteration over a list of possible alternatives is made in order to find one alternative that is a suitable replacement. In box 45 another sensor model than the failed one may be selected and in box 46 it is checked if this selected sensor is compatible with the failed one. The establishing of compatibility may, just like for the antenna compatibility (figure 3), be done in a manner similar to the battery compatibility check described with reference to figure 2.

When, in box 46, a new sensor model has been selected flow continues to box 47, wherein the recommendation can be made to select this particular model. The usage of context is particularly advantageous. An example of context in the case of a temperature sensor would be the usage of a weather service. In this case the measurement retrieved by a sensor in a rural area may be compared to the one reported by the weather service in that area and if the measurement from the sensor is not within a certain margin then it is considered to be erroneous and a

recommendation for a new replacement sensor can be made.

Reverting now to figure 1, a process of replacing a faulty sensor or ordering a new sensor during sensor network bootstrapping is also detailed. Such process may involve use of a 3D printer to construct the replacement sensor and a drone to facilitate its automatic delivery. Bootstrapping generally may refer to the starting of a self-sustaining process that is supposed to proceed without external input. Sensor Network Bootstrapping may accordingly be interpreted as a process of starting the sensor network 2 (Al). In this case, the sensor management node 3 may issue a command (A2) to the sensor maintenance node 5 to create and deploy a new sensor network. This command may relate to more than one sensor, e.g. a list of sensors, their type and coordinates of deployment.

The sensor maintenance node 5 may consult the blueprint database 6 for creating new sensor generation data (A3), e.g. defining sensor type and model. Based on this sensor generation data the new sensors may then be generated. The sensor maintenance node 5 may then issue instructions (A4) to the sensor manufacturer node 7 to create the sensors SI, S2,.., Si,.., Sn according to the new sensor generation data (e.g. comprising blueprints). This may also comprise the maintenance node 5 configuring the sensors according to need, e.g. based on what the sensor is supposed to measure, how it is supposed to report etc. Once the sensor manufacturer node 7 has done creating (A5) the sensors SI, S2,.., Si,.., Sn, it may inform (A6) the sensor maintenance node 5 accordingly, e.g. information about sensor serial numbers, their pickup coordinates etc. The sensor maintenance node 5 may then send (A7) a corresponding notification to the sensor deployment service 8, the notification comprising for instance the pickup location and intended deployment location. The sensor maintenance node 5 may thus use (A7) the sensor deployment service 8 to commission (A8) a pickup and drop-off operation of the newly created sensors SI, S2,.., Si,.., Sn from a designated sensor manufacturer pickup point to the designated location in what will be the new sensor network. The sensor deployment service 8 informs (A9) the sensor maintenance node 5 about the completed commissioning. Once deployment is complete the sensor management node 3 is also notified accordingly (A10), so now it can start putting the new sensor network in operation.

The above described procedure may also be used for replacement of one or more faulty sensors during operation of an existing sensor network 2.

In this case, the sensor management node 3 detects (Al) a fault in a sensor and performs a root cause analysis on the cause to identify the culprit (e.g. depleted battery, environmental parameters such as high/ low temperature, humidity, etc.).

Subsequently, it relays (A2) the fault information to the sensor maintenance node 5, together with metadata on the faulty sensor (i.e. its type and coordinates). The sensor maintenance node 5 retrieves the blueprint of the sensor to be replaced based on the sensor type and tries, based on the fault information, to improve this blueprint in order for this error not to happen again. A simple example would be adding a battery with larger capacity to a sensor which depleted its battery sooner than expected.

In the context of creating a new sensor, with the aim of providing an improved one compared to a previously used sensor, the compatibility of a failed sensor and a candidate replacement sensor is elaborated on a bit further in the following.

A sensor is typically small (or even very small) and it is physically attached to (i.e. connects to) a sensor board. The physical connection may for instance be a 1-wire, Inter-Integrated Circuit (I ² C) connection, Controller Area Network (CAN) interface, or serial peripheral interface (SPI). The sensor board may for instance comprise a microcontroller board, a set of preassembled computer hardware and software e.g. Arduino boards or Libelium's mote runner (a mote being another notation for sensor node), or be assembled in the sensor manufacturer node 7. The sensor board may support a set of interfaces for the sensor, e.g. the above mentioned interfaces. Moreover, on the sensor board there is typically an antenna shield which allows for short-range and/ or long-range

communication. The sensor board also has an interface for connecting a battery or power source. Examples on different shields comprise WiFi, Bluetooth, GSM and even Ethernet.

In view of compatibility, for example when searching for a suitable battery, the proper voltage as expected by the sensor-board may for instance need to be verified. This is just one example on how to ensure the compatibility of a new sensor and its predecessor, various other compatibility checks may be required.

When selecting a sensor, it of course needs to be checked if the sensor senses the same things as its predecessor and also if it has the same way of connecting to the sensor board (e.g. 1-wire, I2C, CAN, SPI). Regarding the selection of antenna technology (refer to figure 3 and corresponding description), when selecting antenna (antenna shields) there is some more freedom compared to e.g. battery selection, since there is available a standardized connector for antennas on top of sensor boards. However, since these standardized connectors are usually short range technologies, it may need to be checked if the antenna technology used between the sensor board (e.g. Wifi) and the sensor management node 2 is compatible (e.g. WiFi to WiFi, Bluetooth to Bluetooth and so on). Finally, the blueprint is sent (A4) to the sensor manufacturer 7, which prints (A5) the sensor using a 3D printer, or creates or obtains the sensor in some other way, and sends (A6) information on the pickup location back to the sensor maintenance node 5. The sensor maintenance node 5 relays (A7) this information to the sensor deployment service 8. The sensor deployment service 8 coordinates its assets, e.g. drones, to pickup the sensor from the designated location. The sensor is delivered (A8) to its intended location in the sensor network 2.

At this point, the sensor management node 5 can do post-deployment operations such as decommissioning the old faulty sensor and commissioning its replacement. The sensor management system 1 and methods therein according the present teachings provide a number of advantages, a few of which are mentioned in the following:

- Reduced operational costs (both monetary and temporal) for sensor network operators as a result of increased level of automation.

- Enables more reliable sensor networks by removing human-in-the-loop in network deployment and maintenance, thus eliminating dependency on human skill.

- Provides greater opportunities for growth and expansion, as a result of cheaper sensor network solutions. - Enables use of better sensor hardware with cheaper research and development that the system provides through an automated fault-detection and sensor design improvements loop.

The various features and embodiments that have been described may be combined in different ways, examples of which are given in the following. Figure 5 illustrates a flow chart of steps of a method 50 in accordance with the present teachings. A method 50 for autonomous operation and maintenance of a sensor network 2 is provided. The method 50 may be executed in one or more nodes 3, 5 of a sensor management system 1. The various functions that are performed according to the method 50 may thus be implemented as being performed in and by different nodes or entities or in and by a single node or entity.

The method 50 comprises establishing 51 one or more requirements for each of one or more sensors SI, S2,.., Si,.., Sn.

The method 50 comprises executing 52 an automated installation process, which may be triggered. The automated installation process comprises: - obtaining 53 information about each of the requested one or more sensors SI, S2,.., Si,.., Sn, the information identifying type of sensor and an intended deployment location thereof,

- acquiring 54, based on the obtained information, the one or more sensors SI, S2,.., Si,.., Sn, - configuring 55 sensor software of each of the one or more sensors SI, S2,.., Si,.., Sn, and

- deploying 56 the one or more sensors SI, S2,.., Si,.., Sn at their respective deployment location. In an embodiment, the establishing 51 comprises:

- detecting a faulty sensor SI, S2,.., Si,.., Sn in an existing sensor network 2, and

- establishing one or more requirements for a replacement sensor.

In a variation of the above embodiment, the detecting a faulty sensor SI, S2,.., Si,.., Sn comprises detecting a sensor SI, S2,.., Si,.., Sn failing to transmit data according to its configuration, or failing to respond to a request, or transmitting erroneous data, or transmitting an error code.

In variations of the above two embodiments, the method 50 comprises establishing type of fault of the faulty sensor SI, S2,.., Si,.., Sn and generating, based at least on the type of fault, a recommendation regarding the replacement sensor to use.

In a variation of the above embodiment, the acquiring 54 is based on the

recommendation .

In various embodiments, the acquiring 54 of the one or more sensors SI, S2,.., Si,.., Sn comprises providing, to a sensor manufacturing device 7, a set of instructions on manufacturing of the one or more sensors SI, S2,.., Si,.., Sn.

In a variation of the above embodiment, the method 50 comprises receiving, in response to the providing, information that the one or more sensors SI, S2,.., Si,.., Sn have been created and dispatched for deployment, and updating a database 4, 6 comprising information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2 about the deployment of the one or more sensors SI, S2,.., Si,.., Sn.

In variations of the above two embodiments, the one or more sensors SI, S2,.., Si,.., Sn are dispatched for deployment by an automated sensor deployment service 8. In various embodiments, the set of instructions on manufacturing comprises one or more of: instructions defining battery to use, instructions defining antenna to use, instructions on software installation and configuration thereof, instructions on housing of sensor. Various other instructions may also be provided. In various embodiments, the method 50 comprises, after the execution of the installation process, updating a database 4, 6 comprising information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2, with information on the deployed one or more sensors SI, S2,.., Si,.., Sn.

In a variation of the above embodiment, the method 50 comprises using a machine learning algorithm and/ or decision tree algorithm for building, based on the information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2, a model on selection of the sensors SI, S2,.., Si,.., Sn. Varying degree of complexity may thus be selected among for building a sensor selection model.

In an embodiment, the establishing 51 comprises obtaining a request for a new sensor network 2 comprising one or more sensors SI, S2,.., Si,.., Sn.

Figure 6 illustrates schematically a sensor management system 1 and means for implementing methods of the present teachings, e.g. the embodiments as described with reference to figure 5. The sensor management system 1 comprises one or more devices, in the figure exemplified by the described sensor management node 3 and the sensor maintenance node 5. As noted earlier, the sensor management system 1 may comprise one or several nodes, and the different steps of the method 50 may hence be performed in a single node or in a distributed manner by several nodes.

The sensor management system 1 comprises one or more a processors 60, 70 comprising any combination of one or more of a central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc. capable of executing software instructions stored in a respective memory 61, 71 which can be a computer program product 61, 71. The processors 60, 70 can be configured to execute any of the various embodiments of the method for instance as described in relation to figure 5, or parts of the steps of the method. Each memory 61, 71 can be any combination of read and write memory (RAM) and read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc. Each memory 61, 71 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The one or more nodes 3, 5 also comprises a respective input/ output device 63, 73 (indicated by I/O in figure 6) for communicating with other entities, e.g. with other devices that have been described. Such input/ output device 63, 73 may comprise a communication interface, for instance configured for wireless communication. For this communication, the nodes 3, 5 may also comprise receiving circuitry,

transmission circuitry, antenna devices etc. (not illustrated).

The sensor management system 1, in particular the nodes 3, 5 thereof, may also comprise additional processing circuitry, schematically indicated at reference numeral 64 and 74, respectively, for implementing the various embodiments according to the present teachings. The present teachings provide computer programs 72, 72 for the sensor management system 1. The computer programs 62, 72 comprises computer program code, which, when executed on at least one processor 60, 70 on sensor management system 1 causes the sensor management system 1 to perform the method 50 according to any of the described embodiments thereof. The present disclosure also encompasses computer program products 61, 71 comprising a computer program 62, 72 for implementing the embodiments of the method as described, and a computer readable means on which the computer program 62, 72 is stored. The computer program product 62, 72 may, as mentioned earlier, be any combination of random access memory (RAM) or read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc.

A sensor management system 1 for autonomous operation and maintenance of a sensor network 2 is provided. The sensor management system 1 comprises one or more nodes 3, 5 configured to: - establish one or more requirements for each of one or more sensors SI, S2,.., Si,.., Sn, - execute an automated installation process, comprising:

- obtain information about each of the requested one or more sensors SI, S2,.., Si,.., Sn , the information identifying type of sensor and an intended

deployment location thereof,

- acquire, based on the obtained information, the one or more sensors SI, S2,.., Si,.., Sn ,

- configure sensor software of each of the one or more sensors SI, S2,.., Si,.., Sn , and

- deploy the one or more sensors SI, S2,.., Si,.., Sn at their respective deployment location.

The sensor management system 1 may be configured to perform the above steps e.g. by comprising one or more processors 60, 70 and memory 61, 71, the memory 61, 71 containing instructions executable by the processor 60, 70, whereby the sensor management system 1 is operative to perform the steps. In case of several processors 60, 70, they may be configured to perform all steps of the method 50 or only part of the steps.

In an embodiment, the sensor management system 1 is configured to establish by:

- detecting a faulty sensor SI, S2,.., Si,.., Sn in an existing sensor network 2, and

- establishing one or more requirements for a replacement sensor.

In an embodiment, the sensor management system 1 is configured to detect a faulty sensor SI, S2,.., Si,.., Sn by detecting a sensor SI, S2,.., Si,.., Sn failing to transmit data according to its configuration, or failing to respond to a request, or transmitting erroneous data, or transmitting an error code.

In an embodiment, the sensor management system 1 is configured to establish type of fault of the faulty sensor SI, S2,.., Si,.., Sn and to generate, based at least on the type of fault, a recommendation regarding the replacement sensor to use. In an embodiment, the sensor management system 1 is configured to acquire the one or more sensors SI, S2,.., Si,.., Sn based on the recommendation.

In an embodiment, the sensor management system 1 is configured to acquire the one or more sensors SI, S2,.., Si,.., Sn by providing, to a sensor manufacturing device 7, a set of instructions on manufacturing of the one or more sensors SI, S2,.., Si,.., Sn .

In an embodiment, the sensor management system 1 is configured to receive, in response to the providing, information that the one or more sensors SI, S2,.., Si,.., Sn have been created and dispatched for deployment, and to update a database 4, 6 comprising information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2 about the deployment of the one or more sensors SI, S2,.., Si,.., Sn .

In an embodiment, the sensor management system 1 is configured to dispatch the one or more sensors SI, S2,.., Si,.., Sn for deployment by an automated sensor deployment service 8.

In various embodiments, the set of instructions on manufacturing comprises one or more of: instructions defining battery to use, instructions defining antenna to use, instructions on software installation and configuration thereof, instructions on housing of sensor.

In an embodiment, the sensor management system 1 is configured to, after the execution of the installation process, update a database 4, 6 comprising information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2, with information on the deployed one or more sensors SI, S2,.., Si,.., Sn .

In an embodiment, the sensor management system 1 is configured to use a machine learning algorithm and/ or decision tree algorithm for building, based on the information on the sensors SI, S2,.., Si,.., Sn of the sensor network 2, a model on selection of the sensors SI, S2,.., Si,.., Sn .

In an embodiment, the sensor management system 1 is configured to establish by obtaining a request for a new sensor network 2 comprising one or more sensors SI, S2,.., Si,.., Sn . The computer program products, or the memories, comprises instructions executable by the one or more processors 60, 70. Such instructions may be comprised in a computer program, or in one or more software modules or function modules.

In an aspect, means are provided, e.g. function modules, that can be implemented using software instructions such as computer program executing in a processor and/ or using hardware, such as application specific integrated circuits, field programmable gate arrays, discrete logical components etc., or any combination thereof.

Figure 7 illustrates a sensor management system comprising function

modules/ software modules for implementing methods of the present disclosure.

A sensor management system is provided comprising a first unit 81 for establishing one or more requirements for each of one or more sensors.

The sensor management system comprises a second unit 82 for executing an automated installation process. For the execution of the steps of the automated installation process, the sensor management system may comprise a third unit 83, a fourth unit 84, a fifth unit 85 and a sixth unit 86.

The sensor management system comprises a third unit 83 for obtaining information about each of the requested one or more sensors, the information identifying type of sensor and an intended deployment location thereof.

The sensor management system comprises a fourth unit 84 for acquiring, based on the obtained information, the one or more.

The sensor management system comprises a fifth unit 85 for configuring sensor software of each of the one or more sensors.

The sensor management system comprises a sixth unit 86 for deploying the one or more sensors at their respective deployment location.

The sensor management system may comprise still other units for implementing the various embodiments according to the present teachings. The invention has mainly been described herein with reference to a few embodiments. However, as is appreciated by a person skilled in the art, other embodiments than the particular ones disclosed herein are equally possible within the scope of the invention, as defined by the appended patent claims.