[go: up one dir, main page]

WO2018046108A1 - Communications module and method - Google Patents

Communications module and method Download PDF

Info

Publication number
WO2018046108A1
WO2018046108A1 PCT/EP2016/071436 EP2016071436W WO2018046108A1 WO 2018046108 A1 WO2018046108 A1 WO 2018046108A1 EP 2016071436 W EP2016071436 W EP 2016071436W WO 2018046108 A1 WO2018046108 A1 WO 2018046108A1
Authority
WO
WIPO (PCT)
Prior art keywords
microcontroller
communications module
sensor
module
sensor systems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2016/071436
Other languages
French (fr)
Inventor
Marcus GÅRDMAN
Cristian Norlin
Niclas JONASSON
Athanasios KARAPANTELAKIS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to PCT/EP2016/071436 priority Critical patent/WO2018046108A1/en
Publication of WO2018046108A1 publication Critical patent/WO2018046108A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/38Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50Service provisioning or reconfiguring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/656Updates while running
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Definitions

  • the present invention relates to a communications module and method, and in particular a communications module and method for interfacing between one or more repository units and one or more microcontroller-sensor systems, for example for handling configuration and/or update information.
  • microcontrollers and sensors exist. For every type of sensor (ranging from those monitoring environmental qualities such as temperature sensors, to actuators such as DC motors, servos but also communication sensors), different communication protocols can exist between such sensors and their associated microcontrollers.
  • FIG. 1 shows an example of such microcontroller-sensor systems 101 .
  • Each microcontroller-sensor system 101 comprises a microcontroller 102 and one or more associated sensors 103.
  • a first microcontroller 102i is associated with three sensors 103n , 103i2 and 103i3, which together form a microcontroller-sensor system 1011.
  • a second microcontroller 1022 is associated with a single sensor 10321, which together form another microcontroller-sensor system 1012, and so on.
  • Different communication protocols may exist between the microcontroller 102i and its associated sensors 103n , 103i2 and 103i3, compared to that of microcontroller 1022 and its associated sensor 10321.
  • the microcontroller 102i may use different communication protocols between two or more of its own associated sensors 103n , 103i2 and 103i3.
  • microcontroller-sensor systems This means that operations such as the mass updating of software or firmware for microcontroller-sensor systems (MSSs) is a process that involves a large operational expense, either requiring a local update of a particular microcontroller-sensor system, for example through serial connection, or replacement of a microcontroller-sensor system with new hardware.
  • MMSs microcontroller-sensor systems
  • a communications module comprising a first interface module for interfacing with one or more microcontroller-sensor systems, MSSs, wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor.
  • the communications module comprises a second interface module for interfacing with one or more repository units.
  • a method in a communications module for interfacing between one or more repository units and one or more microcontroller- sensor systems.
  • the method comprises detecting one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module.
  • the method comprises communicating with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems.
  • the method comprises communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface unit.
  • a microcontroller-sensor system for use with a communications module as described herein.
  • the microcontroller-sensor system comprises a microcontroller and at least one sensor associated with the microcontroller, and an electronic or visual tag for identifying the microcontroller and/or at least one sensor to the communications module.
  • Figure 1 shows examples of microcontroller-sensor systems
  • Figure 2 shows an example of a communications module according to an embodiment
  • Figure 3 shows an example of an application of a communications module according to an embodiment
  • Figure 4 shows an example of a signalling flow according to an embodiment
  • Figure 5 shows an example of a signalling flow according to another embodiment
  • Figure 6 shows an example of a signalling flow according to another embodiment
  • Figure 7 shows an example of a method according to an embodiment
  • Figure 8 shows an example of a wireless network node according to an embodiment
  • FIGS. 9A to 9D show examples of different configurations. Detailed description
  • a communications module for interfacing between one or more microcontroller-sensor systems, MSSs, and one or more repository units.
  • References herein to a repository unit are intended to include a module or node, either network based or cloud based (or a combination of both), which is configured to handle configuration and/or update information, including for example software or firmware, for microcontrollers and/or sensors.
  • a repository unit may also include compiler functionality, for example to compile source code into software binaries on request, prior to sending to a communications module.
  • a repository unit may consist of a software repository (for example a software version control system known as GIT, a subversion, a Web Distributed Authoring and Versioning extension of the Hypertext Transfer Protocol - WEBDAV/HTTP, etc.), a compiler, an interface to the communications module and an interface to a software designer (who updates/creates new software/firmware for microcontrollers and/or sensors).
  • a repository unit may retrieve code from a software repository and compile it to the architecture of the microcontroller of the MSS the communications module is coupled to. Subsequently, a compiled binary may be sent to the communications module.
  • FIG 2 shows an example of a communications module 105 according to an embodiment.
  • the communications module 105 comprises a first interface module 106 for interfacing with one or more microcontroller-sensor systems, MSSs, (not shown in detail), wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor.
  • the communications module 105 comprises a second interface module 107 for interfacing with one or more repository units (not shown in detail).
  • this enables, for example, mass updates to be performed to various MSSs, including different microcontroller-sensor systems, via the communications module 105.
  • Such an embodiment also enables a MSS to be configured by the communications module 105, for example when a new MSS is installed in the vicinity of the communications module 105. In this way a MSS does not necessarily have to be pre-configured prior to installation, with the communications module 105 taking care of this upon detection, or being informed, about the presence of a new MSS.
  • the first interface module 106 may be adapted to receive identifier information from a microcontroller and/or one or more sensors associated with a microcontroller of a MSS. This identifier information can be used by the communications module 105, as described in greater detail later, to establish which types of microcontroller-sensor systems are in the vicinity of the communications module 105, such that the communications module 105 can then communicate with different microcontroller- sensor systems according to their particular communication protocols, while also being able to communicate with one or more repository units to obtain configuration data such as software or firmware relating to configuration information, or update information, relating to one or more different microcontroller-sensor systems.
  • the communications module 105 comprises a processing unit 108 for detecting the type of microcontroller and/or the type of one or more sensors associated with a microcontroller of a MSS, using the received identifier information.
  • the identifier information may comprise a model type or a serial number of a microcontroller and/or sensor.
  • the processing unit 108 is able to identify the type of MSS that it needs to communicate with, and select an appropriate communication protocol for doing so. This may involve consulting a database to obtain the relevant information. Part or whole of such a database may either be located within the communications module 105 itself, or located elsewhere, for example in another network node or nodes, or in a cloud based functional unit.
  • the first interface module 106 is adapted to communicate with the one or more microcontrollers and/or one or more associated sensors of the MSSs using wireless communication.
  • the wireless communication may comprise short-range radio communication, such as radio frequency identification (RFID) communication, or near field communication (NFC), Bluetooth communication or some other form of wireless or optical communication technique.
  • RFID radio frequency identification
  • NFC near field communication
  • the communications module 105 is able to detect or determine which MSSs are in the vicinity of the communications module, for example within a particular threshold distance (for example either a physical distance or signalling distance), and act as an interface between such MSSs and one or more repository units.
  • the communications module 105 may interface with a plurality of repository units.
  • the first interface module 106 comprises an RFID unit for communicating with one or more RFID units located on the one or more microcontrollers and/or associated sensors of the MSSs.
  • the RFID unit of the first interface module 106 may comprise an RFID reader for communication with one or more passive or active RFID tags located on the one or more microcontrollers and/or associated sensors of the MSSs.
  • the communications module 105 is able to identify one or more MSSs in the vicinity of the communications module using some form of short range radio communication technique that does not require prior knowledge of what type of communication protocol should be used to communicate with the MSSs.
  • the first interface module 106 of the communications module is coupled to an imaging unit for imaging visual identification tags located on the one or more microcontrollers-sensor systems.
  • the imaging unit may include, for example, image recognition technology.
  • the visual identification tags may comprise, for example, Quick Response (QR) codes to be imaged by the imaging unit coupled to the communications module 105, thus enabling the type of microcontroller/sensor to be detected by optical means.
  • QR Quick Response
  • the communications module 105 is able, either proactively or reactively, to communicate with one or more repository units for obtaining data relating to the one or more MSSs identified by the communications module 105, for example configuration or update data. It is noted that in the embodiments described herein, other forms of data may be obtained from the one or more repository units.
  • the communications module 105 may comprise a third interface module 109 for communicating data with the one or more MSSs.
  • the third interface module 109 may comprise a wireless link for communicating data between the communications module 105 and the one or more MSSs.
  • the communications module 105 may be adapted, for example in response to a trigger signal, to detect one or more microcontroller-sensor systems using the first interface module 106, communicate with one or more repository units via the second interface unit 107, for example to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, and communicate the obtained configuration and/or update data to the one or more microcontrollers using the third interface unit 109.
  • a trigger signal may be received, for example, in response to a power-up of the communications module, or in response to an update message received from one or more repository units, or in response to a new microcontroller-sensor system being detected in the vicinity of the communications module.
  • a communications module 105 is able to provide data communication functionality via the third interface module 109, which may include for example the communications module 105 programming a microcontroller to interface with sensors the microcontroller is connected to, and offer update functionality to the microcontroller-sensor system in case a software update becomes available.
  • an updating process can cover uploading of a newer version of the microcontroller software ("push") or updating upon detection of new sensor hardware (“pull").
  • Figure 3 shows further details of an application of a communications module 105 according to an embodiment.
  • the communications module 105 of Figure 3 provides an interface between one or more microcontroller-sensor systems 101 (only one shown for clarity) and one or more repository units 1 10 (again, only one shown for clarity).
  • the microcontroller-sensor system 101 comprises a microcontroller 102 connected to one or a plurality of sensors 103 (only one sensor 103 shown for clarity).
  • the microcontroller 102 comprises an RFID unit 1 13
  • the sensor 103 comprises an RFID unit 1 14.
  • the RFID units 1 13, 1 14 contain static information relating to the model of the microcontroller and sensor, respectively. For example, this information could be a sensor model or serial number or alphanumeric identifier, or some other type of identifier.
  • the microcontroller 102 and sensor 103 may communicate over one or more I/O channels 1 15, which may comprise physical or wireless channels, or a combination of both.
  • the I/O channels 1 15 may comprise for example a serial communications link, or a universal serial bus (USB).
  • the communications module 105 comprises a first interface module 106 for interfacing with the microcontroller-sensor system 101 .
  • the first interface module 106 comprises a RFID reader.
  • the RFID reader 106 may communicate with the microcontroller 102 and/or the sensor 103, using RF communication links 1 16 and 1 17, respectively.
  • the RFID units 1 13 and 1 14 of the respective microcontroller 102 and one or more associated sensors 103 comprise passive RFID tags, which the RFID reader 106 of the communications module 105 can communicate with using the communication links 1 16, 1 17.
  • the communication module 105 can identify the microcontroller 102 and sensors 103 directly, i.e. by interrogating the passive RFID tags 1 13, 1 14.
  • the RFID unit 1 13 of the microcontroller 102 comprises a RFID reader while the RFID unit 1 14 of an associated sensor 103 comprises a passive RFID tag.
  • the microcontroller 102 can detect the sensors 103 it is attached to using its RFID reader 1 13 (i.e. that communicates with one or more passive RFID tags 1 14 mounted on one or more respective sensors 103), and report this to the communications module 105, for example via communication between the RFID reader 106 of the communications module 105 and the RFID reader 1 13 of the microcontroller
  • the communications module 105 may, in some examples, still have the option of communicating directly with the sensors 103 (whereby the RFID reader 106 of the communications module 105 interrogates the passive RFID tags 1 14 of the sensors
  • the communications module 105 also comprises a second interface module 107 for interfacing with one or more repository units 1 10. Communication between the second interface module 107 and the one or more repository units 1 10 may be over a long- range radio communications link 1 18, for example a cellular 3G or LTE communications link.
  • the one or more repository units 1 10 may in turn receive software update information or configuration information 1 19 from another node. For example, when a user submits new code on a repository unit 1 10, then there is an update operation. This may comprise, for example, committing new code in Subversion or GIT repositories. Subsequently, this can be used to trigger an update operation on a MSS, as will be described in greater detail below.
  • the communications module 105 comprises a third interface module 109 for communicating data with the microcontroller-sensor system 101.
  • Such data communication over signalling link 1 1 1 may comprise control and/or user plane signalling.
  • the communications module 105 is able to detect one or more microcontroller-sensor systems using the first interface module 106, communicate with one or more repository units via the second interface unit 107, for example to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, and communicate the obtained configuration and/or update data to the one or more microcontrollers using the third interface unit 109.
  • Figure 3 also shows the microcontroller 102 coupled to a power source, for example a battery, which in this example is also used to power the communications module via a power connection 120. It is noted, however, that the communications module 105 and microcontroller 102 may be powered from separate sources.
  • the communications module 105 comprises a mobile device which can be powered on site, and in such a case the communications module 105 can be used to bootstrap multiple MSSs.
  • a drone may be equipped with a cellular communications device, moving around in a large area (e.g. a forest or field). To save power, the drone can be controlled to turn on its communications module when it reaches the next MSS. The drone may be controlled to continuously patrol a certain route with waypoints between MSSs, and perform bootstrapping/update operations periodically.
  • the microcontroller 102 of the MSS 101 may comprise an application programming interface (API) that is configured to provide the following functionality: ⁇ INSTALL new microcontroller software, which accepts requests to install a new version of software for the microcontroller.
  • API application programming interface
  • a microcontroller comes pre-programmed with a basic set of functionality, and in order to support new functionality, the new software binary is uploaded and the microcontroller is instructed to reboot. Further details are provided in Figure 4 below.
  • UPDATE microcontroller software which accepts requests to update a version of software running on the microcontroller.
  • the update functionality may be different than the first install functionality in case the current execution state of the microcontroller needs to be saved in order to resume after the update takes effect. Further details are provided in Figure 5 below.
  • Such an API can be implemented, for example, using a full Transmission Control Protocol/Internet Protocol, TCP/IP, stack (e.g. using Hypertext Transport Protocol, HTTP, REST as the application layer of the stack).
  • the API can be exposed by the microcontroller 102 to other entities over similar I/O channels 1 15 as the sensors 103 (e.g. serial, USB, etc.) or by other means (e.g. wirelessly using Bluetooth or WiFi, etc.), depending on the capabilities of the microcontroller 102.
  • the communications module 105 via its second interface module 107, interfaces with one or more repository units 1 10.
  • a repository unit 1 10 may contain software for various MSS, microcontroller and sensor models. Since the one or more repository units 1 10 can be anywhere in the Internet and the MSSs 101 and communications module 105 deployed anywhere in an area, the communications module 105 may use, for example, long-range radio communication (e.g. including but not limited to 3G, LTE) for communicating with the one or more repository units 1 10 over the link 1 18.
  • long-range radio communication e.g. including but not limited to 3G, LTE
  • the communications module 105 interfaces with the microcontroller 102 in two ways.
  • the communications module 105 interfaces with the microcontroller 102 using RFID in order to receive identifier information, e.g. information about the microcontroller model as well as the sensor models it is connected to in the microcontroller-sensor system 101.
  • identifier information e.g. information about the microcontroller model as well as the sensor models it is connected to in the microcontroller-sensor system 101.
  • the RFID reader 106 of the communications module 105 is adapted, upon bootstrap of the system, to activate all passive RFID tags in the system, and collect all information on sensor-microcontroller identifiers they transmit. This process may be triggered by a "bootstrap trigger".
  • the bootstrap trigger can be automated, for example once the communications module 105 is connected to some source of power source (for example from the microcontroller 102 as shown in Figure 3, or an external power source), or the bootstrap signal can be manual, for example activated by a user pressing a bootstrap trigger input 121 (e.g. button) on the communications module 105.
  • the RFID reader 106 on the communications module 105 can be configured to remain active after the initial setup, for example for the purpose of detecting changes in hardware of the system (e.g. addition of a new MSS, or new sensor or microcontroller within an existing MSS).
  • the communications module 105 interfaces with the microcontroller 102 using communication over the communications link 1 1 1 via the third interface module 109.
  • such communication may involve installing or updating software in the microcontroller 102.
  • the communications module 105 can ask one or more repository units 1 10 for software to run on the microcontroller (based on the types of sensors and the model of the microcontroller).
  • the communications module 105 uses the INSTALL function of the API described above to install software on the microcontroller 102. This is described further in Figure 4 below.
  • the communications module 105 detects through the RFID interface that a change has occurred in the system setup (e.g. a new MSS, microcontroller or sensor has been added), then it instructs for new software from the one or more repository units 1 10 and subsequently uses the UPDATE function of the API described above to update the software on the microcontroller. This is described further in Figure 5 below.
  • a repository unit 1 10 receives notification of an update relating to a MSS, microcontroller or sensor, such as a software update for the code of a microcontroller, then the repository unity 1 10 notifies the communication module 105 about this update. Subsequently, the communications module 105 uses the INFORM function of the API described above to get the version of software currently running on the microcontroller, and performs a comparison with the software version received in the notification of the software repository. If the latter is a more recent version than the former, the communications module 105 issues an UPDATE request towards the microcontroller to update its software. This is described further in Figure 6 below.
  • Figure 4 shows an example of a signalling flow according to an embodiment, for example involving system bootstrapping and the INSTALL function noted above.
  • Figure 4 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
  • the communications module 105 seeks identifier information from the microcontroller 102 and sensor(s) 103. For example, the communications module 105 transmits a "Get Microcontroller Model” message 402 to the microcontroller 102, and the microcontroller 102 responds with its microcontroller identifier information 403, "MCJD". Likewise, the communications module 105 transmits a "Get Sensor Models" message 404 to the one or more sensors 103 (only one shown for clarity), and the sensors 103 respond with a list of sensor identifier information 405, "Nst[sensorlD]".
  • the information above is obtained via the first interface module 106 of the communications module 105, for example using RFID, NFC, Bluetooth, optical, or some other form of short-range radio communication.
  • the communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3).
  • the communications module 105 sends a message 406 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]".
  • one or more repository units 1 10 return a message 407 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message.
  • This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
  • the communications module 105 is then adapted to perform an INSTALL procedure as noted earlier, by sending an install message 408 to the microcontroller 102, for example by sending a "INSTALL[Software_Binaries]" message.
  • the microcontroller 102 may send an acknowledgement signal 409, confirming that the INSTALL message has been safely received, or that the installation procedure has been successful.
  • Figure 4 shows an example of how a microcontroller-sensor system can be configured using a communication module 105 following a bootstrap trigger, by installing software or firmware onto a microcontroller and/or sensors of a microcontroller-sensor system.
  • Figure 5 shows an example of a signalling flow according to another embodiment, for example where the communications module detects a change in a MSS setup, and involving an UPDATE function as noted above.
  • Figure 5 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
  • the communication module 105 may be configured to periodically perform a check operation 501 , to determine whether there have been any changes to the network, for example changes in hardware involving the addition of a new microcontroller-sensor system, or additional microcontrollers or sensors per se, in the vicinity of the communications module 105.
  • the communications module 105 seeks identifier information from one or more microcontrollers 102 and sensor 103. For example, the communications module 105 transmits a "Get Microcontroller Model" message 502 to one or more microcontrollers 102 (only one shown for clarity), and the microcontrollers 102 respond with their respective microcontroller identifier information 503, "MCJD".
  • this may involve the use of RFID or optical (or other means) for detecting identifier information relating to the microcontrollers.
  • this would automatically detect any microcontroller RFID tags that are within range of the RFID reader of the communication module 105.
  • the communications module 105 transmits a "Get Sensor Models" message 504 to the one or more sensors 103 (only one shown for clarity), and the sensors 103 respond with a list of sensor identifier information 505, "Nst[sensorlD]".
  • this would automatically detect any sensor RFID tags that are within range of the active RFID reader of the communication module 105.
  • the sensor identifier information may be obtained via an associated microcontroller, for example if a microcontroller is aware of this information.
  • steps 504 and 505 of Figure 5 may be omitted in such embodiments.
  • the communications module 105 then performs a comparison, step 506, to determine whether the list of detected microcontrollers and sensors is the same as a list previously generated from a previous iteration of this loop.
  • the communications module 105 may comprise a memory for storing information relating to microcontroller-sensor systems it is currently interfacing with.
  • the procedure 507 is performed. This is similar to that of Figure 4 above, whereby the communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3).
  • the communications module 105 sends a message 508 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]".
  • the communications module 105 may either request software for just newly detected MSSs, or for all MSSs currently detected in the setup (e.g. in order to obtain most up- to-date software for any existing MSSs).
  • one or more repository units 1 10 return a message 509 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message.
  • This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
  • the communications module 105 is then adapted to perform an UPDATE procedure as noted earlier, by sending an UPDATE message 510 to the microcontroller 102, for example by sending a "UPDATE[Software_Binaries]" message.
  • the microcontroller 102 may send an acknowledgement signal 51 1 , confirming that the UPDATE message has been safely received, or that the update procedure has been successful.
  • Figure 5 shows an example of how a communications module 105 can detect changes to MSS setup, and how the microcontroller-sensor systems can be configured using a communication module 105 following such a change.
  • Figure 6 shows an example of a signalling flow according to another embodiment, for example where the communications module is informed of an update from a repository unit, and involving an INFORM function as noted above.
  • Figure 6 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
  • a repository unit 1 10 sends an update message 601 to the communication module 105, e.g. a "Update in code [Lates /ersion]" message.
  • the communications module 105 is configured to send an INFORM request message 602 to a microcontroller 102 it is interfaced with, seeking information about the version of software currently running on the microcontroller 102.
  • the microcontroller 102 returns a message 603 informing the communications module about the version of software it currently has installed, e.g. a "lnstalled_version" message.
  • the communications module 105 then performs a check to determine whether the microcontroller has the latest version of software already installed. If so, no further action is required. If not, the procedure 606 is performed. This is similar to that of Figures 4 and 5 above, whereby the communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3).
  • the communications module 105 sends a message 607 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]".
  • the communications module 105 requests software where it has been determined in step 605 that a microcontroller is not currently running the most recent version of software.
  • a repository unit 1 10 returns a message 608 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message.
  • This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
  • the communications module 105 is then adapted to perform an UPDATE procedure as noted earlier, by sending an UPDATE message 609 to the microcontroller 102, for example by sending a "UPDATE[Software_Binaries]" message.
  • the microcontroller 102 may send an acknowledgement signal 610, confirming that the UPDATE message has been safely received, or that the update procedure has been successful.
  • Figure 6 shows an example of how a communications module 105 is informed of an update from a repository unit.
  • the communications module 105 may comprise a memory for storing information relating to microcontroller-sensor systems it is currently interfacing with, and the current versions of software installed in such microcontroller-sensor systems. In such embodiments the INFORM procedure of Figure 6 may be omitted if desired.
  • Figure 7 shows an example of a method in a communications module according to an embodiment, for interfacing between one or more repository units and one or more microcontroller-sensor systems.
  • the method comprises detecting one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module, step 701.
  • the method comprises communicating with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, step 703.
  • the method further comprises communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module, step 705.
  • the step of detecting may comprise receiving identifier information from a microcontroller and/or one or more sensors associated with a microcontroller.
  • the method may comprise detecting the type of microcontroller and/or the type of one or more sensors associated with the microcontroller using the received identifier information.
  • the step of detecting may comprise communicating with the one or more microcontroller-sensor systems using short-range radio communication, or radio frequency identification, RFID, communication, or near field communication, NFC, or Bluetooth communication, in order to obtain the identifier information.
  • the step of detecting comprises controlling an RFID reader to communicate with one or more passive RFID tags located on one or more microcontrollers and/or associated sensors.
  • the step of detecting may comprise receiving the identifier information from an imaging unit for imaging visual identifier information, for example QR codes, on the one or more microcontroller-sensor systems.
  • the method may further comprise the step of receiving a trigger signal in response to a power-up of the communications module, or in response to an update message received from one or more repository units, or in response to a new microcontroller- sensor system being detected in the vicinity of the communications module, and performing the detecting step in response to receiving the trigger signal.
  • a microcontroller-sensor system for use with a communications module as described herein.
  • the microcontroller-sensor system comprises a microcontroller, at least one sensor associated with the microcontroller, and an electronic or visual tag for identifying the microcontroller and/or at least one sensor to the communications module.
  • FIG. 8 shows an example of a wireless network node 800 according to another embodiment, for interfacing between one or more repository units and one or more microcontroller-sensor systems.
  • the wireless network node 800 comprises a processor 801 and a memory 803, said memory 803 containing instructions executable by said processor 801.
  • the wireless network node 800 is operative to: detect one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module; communicate with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems; and communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module.
  • the first interface module is a type of interface module that is capable of obtaining identifier information relating to one or more MSSs without having specific knowledge of a particular type of communication protocol used by a MSS, e.g. by using a standardised RFID link, with the third interface module then being used to communicate user and/or control plane signalling with the MSS, once the type of MSS has been determined from the identifier information.
  • the embodiments can be deployed wirelessly in the field, which can be particularly advantageous for remote sensor deployments (for example in remote areas such as forests, fields, etc.), where wireline communication is impossible. This applies to lifecycle operations, i.e. bootstrapping, updating during operation and decommissioning.
  • the embodiments described above also have an advantage of enabling the functionality of a MSS to be repurposed during its lifetime.
  • Figures 9A to 9D provide examples of different applications of a communications module 105.
  • Figure 9A relates to an example whereby a communications module 105 is configured to interface between a single microcontroller-sensor system 101 and a plurality of repository units 1 10i to 1 10M.
  • the plurality of repository units 1 10i to 1 10M may contain software or firmware relating to a plurality of sensors (not shown) associated with the MSS 101 , and/or the microcontroller of the MSS 101.
  • the communications module 105 may comprise a second interface module 107 as described in the embodiments above. It is noted that, in such embodiments having two or more repository units, a second interface module 107 of the communications module 105 may comprise a single interface module which is capable of communicating with multiple repository units, or two or more separate interface modules for interfacing with two or more repository units.
  • Figure 9B relates to an example whereby a communications module 105 is configured to interface between a single microcontroller-sensor system 101 and a single repository unit 1 10, whereby the repository unit 1 10 contains software or firmware relating to the MSS 101 , including the microcontroller and/or one or more sensors of the MSS 101 .
  • Figure 9C relates to an example whereby a communications module 105 is configured to interface between a plurality of microcontroller-sensor systems (MMSs) 1011 to 101 N and a single repository unit 1 10, whereby the repository unit 1 10 contains software or firmware relating to the plurality of MSSs 1011 to 101 N, including the microcontrollers and/or one or more sensors of the MSSs 1011 to 101 N.
  • MMSs microcontroller-sensor systems
  • Figure 9D relates to an example whereby a communications module 105 is configured to interface between a plurality of microcontroller-sensor systems (MMSs) 1011 to 101 N and a plurality of repository units 1 10i to 1 10M, whereby the plurality of repository units 1 10i to 1 10M contain software or firmware relating to the plurality of MSSs 1011 to 101 N, including the microcontrollers and/or one or more sensors of the MSSs 1011 to 101 N.
  • MMSs microcontroller-sensor systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

A communications module (105) comprises a first interface module (106) for interfacing with one or more microcontroller-sensor systems, MSSs, wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor. The communications module (105) comprises a second interface module (107) for interfacing with one or more repository units.

Description

Communications Module and Method
Technical Field
The present invention relates to a communications module and method, and in particular a communications module and method for interfacing between one or more repository units and one or more microcontroller-sensor systems, for example for handling configuration and/or update information.
Background
Currently, many different types of microcontrollers and sensors exist. For every type of sensor (ranging from those monitoring environmental qualities such as temperature sensors, to actuators such as DC motors, servos but also communication sensors), different communication protocols can exist between such sensors and their associated microcontrollers.
Figure 1 shows an example of such microcontroller-sensor systems 101 . Each microcontroller-sensor system 101 comprises a microcontroller 102 and one or more associated sensors 103. In the example of Figure 1 a first microcontroller 102i is associated with three sensors 103n , 103i2 and 103i3, which together form a microcontroller-sensor system 1011. A second microcontroller 1022 is associated with a single sensor 10321, which together form another microcontroller-sensor system 1012, and so on. Different communication protocols may exist between the microcontroller 102i and its associated sensors 103n , 103i2 and 103i3, compared to that of microcontroller 1022 and its associated sensor 10321. Indeed, the microcontroller 102i may use different communication protocols between two or more of its own associated sensors 103n , 103i2 and 103i3.
This fragmentation of different communication protocols between sensors and microcontrollers has led to the evolution of separate vertical solutions for pairing specific types of microcontrollers 102 with specific types of sensors 103.
This means that operations such as the mass updating of software or firmware for microcontroller-sensor systems (MSSs) is a process that involves a large operational expense, either requiring a local update of a particular microcontroller-sensor system, for example through serial connection, or replacement of a microcontroller-sensor system with new hardware. In production environments, microcontroller-sensor systems do not offer an update functionality, and come pre-packaged with specific code from the manufacturer.
In future 5th generation (5G) communication networks, it is expected that there will be a proliferation in the number of microcontroller-sensor systems. As such the divergence in different communication protocols between microcontrollers and sensors, or the sensors they control, is likely to increase.
Summary
It is an aim of the embodiments described herein to provide a method and apparatus which obviate or reduce at least one or more of the disadvantages mentioned above. According to a first aspect there is provided a communications module comprising a first interface module for interfacing with one or more microcontroller-sensor systems, MSSs, wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor. The communications module comprises a second interface module for interfacing with one or more repository units.
According to another aspect there is provided a method in a communications module for interfacing between one or more repository units and one or more microcontroller- sensor systems. The method comprises detecting one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module. The method comprises communicating with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems. The method comprises communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface unit.
According to another aspect there is provided a microcontroller-sensor system for use with a communications module as described herein. The microcontroller-sensor system comprises a microcontroller and at least one sensor associated with the microcontroller, and an electronic or visual tag for identifying the microcontroller and/or at least one sensor to the communications module.
Brief description of the drawings
For a better understanding of examples described herein, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which: Figure 1 shows examples of microcontroller-sensor systems:
Figure 2 shows an example of a communications module according to an embodiment;
Figure 3 shows an example of an application of a communications module according to an embodiment;
Figure 4 shows an example of a signalling flow according to an embodiment;
Figure 5 shows an example of a signalling flow according to another embodiment;
Figure 6 shows an example of a signalling flow according to another embodiment;
Figure 7 shows an example of a method according to an embodiment; Figure 8 shows an example of a wireless network node according to an embodiment; and
Figures 9A to 9D show examples of different configurations. Detailed description
The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. But it will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
According to embodiments described herein, there is provided a communications module for interfacing between one or more microcontroller-sensor systems, MSSs, and one or more repository units. References herein to a repository unit are intended to include a module or node, either network based or cloud based (or a combination of both), which is configured to handle configuration and/or update information, including for example software or firmware, for microcontrollers and/or sensors. A repository unit may also include compiler functionality, for example to compile source code into software binaries on request, prior to sending to a communications module. For example, a repository unit may consist of a software repository (for example a software version control system known as GIT, a subversion, a Web Distributed Authoring and Versioning extension of the Hypertext Transfer Protocol - WEBDAV/HTTP, etc.), a compiler, an interface to the communications module and an interface to a software designer (who updates/creates new software/firmware for microcontrollers and/or sensors). Thus, as will be described in greater detail later, upon request from the communications module or when new code is available (e.g. committed from a user), a repository unit may retrieve code from a software repository and compile it to the architecture of the microcontroller of the MSS the communications module is coupled to. Subsequently, a compiled binary may be sent to the communications module.
Figure 2 shows an example of a communications module 105 according to an embodiment. The communications module 105 comprises a first interface module 106 for interfacing with one or more microcontroller-sensor systems, MSSs, (not shown in detail), wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor. The communications module 105 comprises a second interface module 107 for interfacing with one or more repository units (not shown in detail).
By having a communications module 105 interfaced between one or more repository units and one or more MSSs, this enables, for example, mass updates to be performed to various MSSs, including different microcontroller-sensor systems, via the communications module 105. Such an embodiment also enables a MSS to be configured by the communications module 105, for example when a new MSS is installed in the vicinity of the communications module 105. In this way a MSS does not necessarily have to be pre-configured prior to installation, with the communications module 105 taking care of this upon detection, or being informed, about the presence of a new MSS.
The first interface module 106 may be adapted to receive identifier information from a microcontroller and/or one or more sensors associated with a microcontroller of a MSS. This identifier information can be used by the communications module 105, as described in greater detail later, to establish which types of microcontroller-sensor systems are in the vicinity of the communications module 105, such that the communications module 105 can then communicate with different microcontroller- sensor systems according to their particular communication protocols, while also being able to communicate with one or more repository units to obtain configuration data such as software or firmware relating to configuration information, or update information, relating to one or more different microcontroller-sensor systems.
In one example, the communications module 105 comprises a processing unit 108 for detecting the type of microcontroller and/or the type of one or more sensors associated with a microcontroller of a MSS, using the received identifier information. For example, the identifier information may comprise a model type or a serial number of a microcontroller and/or sensor. In this way the processing unit 108 is able to identify the type of MSS that it needs to communicate with, and select an appropriate communication protocol for doing so. This may involve consulting a database to obtain the relevant information. Part or whole of such a database may either be located within the communications module 105 itself, or located elsewhere, for example in another network node or nodes, or in a cloud based functional unit.
In one embodiment the first interface module 106 is adapted to communicate with the one or more microcontrollers and/or one or more associated sensors of the MSSs using wireless communication. For example, the wireless communication may comprise short-range radio communication, such as radio frequency identification (RFID) communication, or near field communication (NFC), Bluetooth communication or some other form of wireless or optical communication technique. In this way the communications module 105 is able to detect or determine which MSSs are in the vicinity of the communications module, for example within a particular threshold distance (for example either a physical distance or signalling distance), and act as an interface between such MSSs and one or more repository units. In some examples it is noted that the communications module 105 may interface with a plurality of repository units.
As will be described later in Figure 3, in one embodiment the first interface module 106 comprises an RFID unit for communicating with one or more RFID units located on the one or more microcontrollers and/or associated sensors of the MSSs. For example, the RFID unit of the first interface module 106 may comprise an RFID reader for communication with one or more passive or active RFID tags located on the one or more microcontrollers and/or associated sensors of the MSSs.
In this way the communications module 105 is able to identify one or more MSSs in the vicinity of the communications module using some form of short range radio communication technique that does not require prior knowledge of what type of communication protocol should be used to communicate with the MSSs.
As an alternative to using a RFID tag or other form of short range radio communication, according to another embodiment the first interface module 106 of the communications module is coupled to an imaging unit for imaging visual identification tags located on the one or more microcontrollers-sensor systems. The imaging unit may include, for example, image recognition technology. The visual identification tags may comprise, for example, Quick Response (QR) codes to be imaged by the imaging unit coupled to the communications module 105, thus enabling the type of microcontroller/sensor to be detected by optical means. Using the identifier information, the communications module 105 is able, either proactively or reactively, to communicate with one or more repository units for obtaining data relating to the one or more MSSs identified by the communications module 105, for example configuration or update data. It is noted that in the embodiments described herein, other forms of data may be obtained from the one or more repository units.
The communications module 105 may comprise a third interface module 109 for communicating data with the one or more MSSs. For example, the third interface module 109 may comprise a wireless link for communicating data between the communications module 105 and the one or more MSSs.
In such embodiments the communications module 105 may be adapted, for example in response to a trigger signal, to detect one or more microcontroller-sensor systems using the first interface module 106, communicate with one or more repository units via the second interface unit 107, for example to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, and communicate the obtained configuration and/or update data to the one or more microcontrollers using the third interface unit 109.
A trigger signal may be received, for example, in response to a power-up of the communications module, or in response to an update message received from one or more repository units, or in response to a new microcontroller-sensor system being detected in the vicinity of the communications module.
Thus, in addition to using the first interface module 106 to detect, for example, what type of hardware a microcontroller-sensor system includes, a communications module 105 is able to provide data communication functionality via the third interface module 109, which may include for example the communications module 105 programming a microcontroller to interface with sensors the microcontroller is connected to, and offer update functionality to the microcontroller-sensor system in case a software update becomes available. As will be described below, an updating process can cover uploading of a newer version of the microcontroller software ("push") or updating upon detection of new sensor hardware ("pull"). Figure 3 shows further details of an application of a communications module 105 according to an embodiment. The communications module 105 of Figure 3 provides an interface between one or more microcontroller-sensor systems 101 (only one shown for clarity) and one or more repository units 1 10 (again, only one shown for clarity). The microcontroller-sensor system 101 comprises a microcontroller 102 connected to one or a plurality of sensors 103 (only one sensor 103 shown for clarity). In this example the microcontroller 102 comprises an RFID unit 1 13, and the sensor 103 comprises an RFID unit 1 14. The RFID units 1 13, 1 14 contain static information relating to the model of the microcontroller and sensor, respectively. For example, this information could be a sensor model or serial number or alphanumeric identifier, or some other type of identifier.
It is noted that the microcontroller 102 and sensor 103 may communicate over one or more I/O channels 1 15, which may comprise physical or wireless channels, or a combination of both. The I/O channels 1 15 may comprise for example a serial communications link, or a universal serial bus (USB).
The communications module 105 comprises a first interface module 106 for interfacing with the microcontroller-sensor system 101 . In this embodiment the first interface module 106 comprises a RFID reader. The RFID reader 106 may communicate with the microcontroller 102 and/or the sensor 103, using RF communication links 1 16 and 1 17, respectively.
In one embodiment, the RFID units 1 13 and 1 14 of the respective microcontroller 102 and one or more associated sensors 103 comprise passive RFID tags, which the RFID reader 106 of the communications module 105 can communicate with using the communication links 1 16, 1 17. In such an embodiment the communication module 105 can identify the microcontroller 102 and sensors 103 directly, i.e. by interrogating the passive RFID tags 1 13, 1 14. In another embodiment, the RFID unit 1 13 of the microcontroller 102 comprises a RFID reader while the RFID unit 1 14 of an associated sensor 103 comprises a passive RFID tag. In such an embodiment the microcontroller 102 can detect the sensors 103 it is attached to using its RFID reader 1 13 (i.e. that communicates with one or more passive RFID tags 1 14 mounted on one or more respective sensors 103), and report this to the communications module 105, for example via communication between the RFID reader 106 of the communications module 105 and the RFID reader 1 13 of the microcontroller
102 over communications link 1 16. Although information relating to the sensors 103 may be obtained via the microcontroller 102 in such an embodiment, the communications module 105 may, in some examples, still have the option of communicating directly with the sensors 103 (whereby the RFID reader 106 of the communications module 105 interrogates the passive RFID tags 1 14 of the sensors
103 directly over communications link 1 17).
The communications module 105 also comprises a second interface module 107 for interfacing with one or more repository units 1 10. Communication between the second interface module 107 and the one or more repository units 1 10 may be over a long- range radio communications link 1 18, for example a cellular 3G or LTE communications link. The one or more repository units 1 10 may in turn receive software update information or configuration information 1 19 from another node. For example, when a user submits new code on a repository unit 1 10, then there is an update operation. This may comprise, for example, committing new code in Subversion or GIT repositories. Subsequently, this can be used to trigger an update operation on a MSS, as will be described in greater detail below.
The communications module 105 comprises a third interface module 109 for communicating data with the microcontroller-sensor system 101. Such data communication over signalling link 1 1 1 may comprise control and/or user plane signalling.
As mentioned earlier, the communications module 105 is able to detect one or more microcontroller-sensor systems using the first interface module 106, communicate with one or more repository units via the second interface unit 107, for example to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, and communicate the obtained configuration and/or update data to the one or more microcontrollers using the third interface unit 109. Figure 3 also shows the microcontroller 102 coupled to a power source, for example a battery, which in this example is also used to power the communications module via a power connection 120. It is noted, however, that the communications module 105 and microcontroller 102 may be powered from separate sources. In one example the communications module 105 comprises a mobile device which can be powered on site, and in such a case the communications module 105 can be used to bootstrap multiple MSSs. In another example, a drone may be equipped with a cellular communications device, moving around in a large area (e.g. a forest or field). To save power, the drone can be controlled to turn on its communications module when it reaches the next MSS. The drone may be controlled to continuously patrol a certain route with waypoints between MSSs, and perform bootstrapping/update operations periodically.
The microcontroller 102 of the MSS 101 may comprise an application programming interface (API) that is configured to provide the following functionality: · INSTALL new microcontroller software, which accepts requests to install a new version of software for the microcontroller. Typically, a microcontroller comes pre-programmed with a basic set of functionality, and in order to support new functionality, the new software binary is uploaded and the microcontroller is instructed to reboot. Further details are provided in Figure 4 below.
• UPDATE microcontroller software, which accepts requests to update a version of software running on the microcontroller. The update functionality may be different than the first install functionality in case the current execution state of the microcontroller needs to be saved in order to resume after the update takes effect. Further details are provided in Figure 5 below.
• INFORM, which transmits information about the current version and type of the software running on the microcontroller. Further details are provided in Figure 6 below. Such an API can be implemented, for example, using a full Transmission Control Protocol/Internet Protocol, TCP/IP, stack (e.g. using Hypertext Transport Protocol, HTTP, REST as the application layer of the stack). Furthermore, the API can be exposed by the microcontroller 102 to other entities over similar I/O channels 1 15 as the sensors 103 (e.g. serial, USB, etc.) or by other means (e.g. wirelessly using Bluetooth or WiFi, etc.), depending on the capabilities of the microcontroller 102.
During use, the communications module 105, via its second interface module 107, interfaces with one or more repository units 1 10. A repository unit 1 10 may contain software for various MSS, microcontroller and sensor models. Since the one or more repository units 1 10 can be anywhere in the Internet and the MSSs 101 and communications module 105 deployed anywhere in an area, the communications module 105 may use, for example, long-range radio communication (e.g. including but not limited to 3G, LTE) for communicating with the one or more repository units 1 10 over the link 1 18.
From the embodiment of Figure 3 it can be seen that the communications module 105 interfaces with the microcontroller 102 in two ways.
First, the communications module 105 interfaces with the microcontroller 102 using RFID in order to receive identifier information, e.g. information about the microcontroller model as well as the sensor models it is connected to in the microcontroller-sensor system 101. In some examples the RFID reader 106 of the communications module 105 is adapted, upon bootstrap of the system, to activate all passive RFID tags in the system, and collect all information on sensor-microcontroller identifiers they transmit. This process may be triggered by a "bootstrap trigger". The bootstrap trigger can be automated, for example once the communications module 105 is connected to some source of power source (for example from the microcontroller 102 as shown in Figure 3, or an external power source), or the bootstrap signal can be manual, for example activated by a user pressing a bootstrap trigger input 121 (e.g. button) on the communications module 105. The RFID reader 106 on the communications module 105 can be configured to remain active after the initial setup, for example for the purpose of detecting changes in hardware of the system (e.g. addition of a new MSS, or new sensor or microcontroller within an existing MSS).
Second, the communications module 105 interfaces with the microcontroller 102 using communication over the communications link 1 1 1 via the third interface module 109. For example, using the API described above, such communication may involve installing or updating software in the microcontroller 102. For example, during bootstrapping and after the polling of sensor/microcontroller models from the RFID interface, the communications module 105 can ask one or more repository units 1 10 for software to run on the microcontroller (based on the types of sensors and the model of the microcontroller). Subsequently, the communications module 105 uses the INSTALL function of the API described above to install software on the microcontroller 102. This is described further in Figure 4 below.
Later during operation, if the communications module 105 detects through the RFID interface that a change has occurred in the system setup (e.g. a new MSS, microcontroller or sensor has been added), then it instructs for new software from the one or more repository units 1 10 and subsequently uses the UPDATE function of the API described above to update the software on the microcontroller. This is described further in Figure 5 below.
In another scenario, if a repository unit 1 10 receives notification of an update relating to a MSS, microcontroller or sensor, such as a software update for the code of a microcontroller, then the repository unity 1 10 notifies the communication module 105 about this update. Subsequently, the communications module 105 uses the INFORM function of the API described above to get the version of software currently running on the microcontroller, and performs a comparison with the software version received in the notification of the software repository. If the latter is a more recent version than the former, the communications module 105 issues an UPDATE request towards the microcontroller to update its software. This is described further in Figure 6 below.
Figure 4 shows an example of a signalling flow according to an embodiment, for example involving system bootstrapping and the INSTALL function noted above. In particular, Figure 4 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
In response to the communication module 105 receiving a bootstrap trigger signal 401 , the communications module seeks identifier information from the microcontroller 102 and sensor(s) 103. For example, the communications module 105 transmits a "Get Microcontroller Model" message 402 to the microcontroller 102, and the microcontroller 102 responds with its microcontroller identifier information 403, "MCJD". Likewise, the communications module 105 transmits a "Get Sensor Models" message 404 to the one or more sensors 103 (only one shown for clarity), and the sensors 103 respond with a list of sensor identifier information 405, "Nst[sensorlD]".
The information above is obtained via the first interface module 106 of the communications module 105, for example using RFID, NFC, Bluetooth, optical, or some other form of short-range radio communication.
The communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3). The communications module 105 sends a message 406 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]".
In response one or more repository units 1 10 return a message 407 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message. This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
The communications module 105 is then adapted to perform an INSTALL procedure as noted earlier, by sending an install message 408 to the microcontroller 102, for example by sending a "INSTALL[Software_Binaries]" message.
The microcontroller 102 may send an acknowledgement signal 409, confirming that the INSTALL message has been safely received, or that the installation procedure has been successful.
Thus, Figure 4 shows an example of how a microcontroller-sensor system can be configured using a communication module 105 following a bootstrap trigger, by installing software or firmware onto a microcontroller and/or sensors of a microcontroller-sensor system.
Figure 5 shows an example of a signalling flow according to another embodiment, for example where the communications module detects a change in a MSS setup, and involving an UPDATE function as noted above. In particular, Figure 5 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
The communication module 105 may be configured to periodically perform a check operation 501 , to determine whether there have been any changes to the network, for example changes in hardware involving the addition of a new microcontroller-sensor system, or additional microcontrollers or sensors per se, in the vicinity of the communications module 105. The communications module 105 seeks identifier information from one or more microcontrollers 102 and sensor 103. For example, the communications module 105 transmits a "Get Microcontroller Model" message 502 to one or more microcontrollers 102 (only one shown for clarity), and the microcontrollers 102 respond with their respective microcontroller identifier information 503, "MCJD". As described above in Figures 2 and 3, this may involve the use of RFID or optical (or other means) for detecting identifier information relating to the microcontrollers. In an RFID type embodiment, this would automatically detect any microcontroller RFID tags that are within range of the RFID reader of the communication module 105. Likewise, the communications module 105 transmits a "Get Sensor Models" message 504 to the one or more sensors 103 (only one shown for clarity), and the sensors 103 respond with a list of sensor identifier information 505, "Nst[sensorlD]". Again, in an RFID type embodiment, this would automatically detect any sensor RFID tags that are within range of the active RFID reader of the communication module 105. It is noted that in this embodiment, and other embodiments described herein, the sensor identifier information may be obtained via an associated microcontroller, for example if a microcontroller is aware of this information. As such, steps 504 and 505 of Figure 5 (and 404 and 405 of Figure 4) may be omitted in such embodiments.
The communications module 105 then performs a comparison, step 506, to determine whether the list of detected microcontrollers and sensors is the same as a list previously generated from a previous iteration of this loop. For this purpose the communications module 105 may comprise a memory for storing information relating to microcontroller-sensor systems it is currently interfacing with.
If a change in MSS setup is detected, the procedure 507 is performed. This is similar to that of Figure 4 above, whereby the communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3). The communications module 105 sends a message 508 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]". The communications module 105 may either request software for just newly detected MSSs, or for all MSSs currently detected in the setup (e.g. in order to obtain most up- to-date software for any existing MSSs).
In response one or more repository units 1 10 return a message 509 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message. This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
The communications module 105 is then adapted to perform an UPDATE procedure as noted earlier, by sending an UPDATE message 510 to the microcontroller 102, for example by sending a "UPDATE[Software_Binaries]" message.
The microcontroller 102 may send an acknowledgement signal 51 1 , confirming that the UPDATE message has been safely received, or that the update procedure has been successful. Thus, Figure 5 shows an example of how a communications module 105 can detect changes to MSS setup, and how the microcontroller-sensor systems can be configured using a communication module 105 following such a change.
Figure 6 shows an example of a signalling flow according to another embodiment, for example where the communications module is informed of an update from a repository unit, and involving an INFORM function as noted above. In particular, Figure 6 shows an example of the messages that may be transmitted between the communications module 105, a repository unit 1 10, the microcontroller 102 and sensors 103.
If there have been any form of updates relating to software associated with any of the microcontrollers or sensors, a repository unit 1 10 sends an update message 601 to the communication module 105, e.g. a "Update in code [Lates /ersion]" message. Upon receipt of such a message 601 , the communications module 105 is configured to send an INFORM request message 602 to a microcontroller 102 it is interfaced with, seeking information about the version of software currently running on the microcontroller 102. The microcontroller 102 returns a message 603 informing the communications module about the version of software it currently has installed, e.g. a "lnstalled_version" message.
The communications module 105 then performs a check to determine whether the microcontroller has the latest version of software already installed. If so, no further action is required. If not, the procedure 606 is performed. This is similar to that of Figures 4 and 5 above, whereby the communications module 105 is then adapted to interface with one or more repository units 1 10 (for example using the second interface module 107 shown in Figures 2 and 3). The communications module 105 sends a message 607 requesting software for the identified microcontroller and/or sensor(s), such message including the identifier information previously received at the communications module 105, e.g. a message "GET_Software[MC_ID, list[sensorlD]]". In this way the communications module 105 requests software where it has been determined in step 605 that a microcontroller is not currently running the most recent version of software. In response a repository unit 1 10 returns a message 608 containing software relating to the microcontroller and/or sensor(s), for example a "Software_Binaries" message. This message may comprise configuration software or firmware relating to the microcontroller and/or sensor(s).
The communications module 105 is then adapted to perform an UPDATE procedure as noted earlier, by sending an UPDATE message 609 to the microcontroller 102, for example by sending a "UPDATE[Software_Binaries]" message. The microcontroller 102 may send an acknowledgement signal 610, confirming that the UPDATE message has been safely received, or that the update procedure has been successful.
Thus, Figure 6 shows an example of how a communications module 105 is informed of an update from a repository unit.
The communications module 105 may comprise a memory for storing information relating to microcontroller-sensor systems it is currently interfacing with, and the current versions of software installed in such microcontroller-sensor systems. In such embodiments the INFORM procedure of Figure 6 may be omitted if desired.
Figure 7 shows an example of a method in a communications module according to an embodiment, for interfacing between one or more repository units and one or more microcontroller-sensor systems. The method comprises detecting one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module, step 701. The method comprises communicating with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems, step 703. The method further comprises communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module, step 705.
The step of detecting may comprise receiving identifier information from a microcontroller and/or one or more sensors associated with a microcontroller. Prior to the step of communicating with the one or more repository units, the method may comprise detecting the type of microcontroller and/or the type of one or more sensors associated with the microcontroller using the received identifier information. For example, the step of detecting may comprise communicating with the one or more microcontroller-sensor systems using short-range radio communication, or radio frequency identification, RFID, communication, or near field communication, NFC, or Bluetooth communication, in order to obtain the identifier information. In some examples the step of detecting comprises controlling an RFID reader to communicate with one or more passive RFID tags located on one or more microcontrollers and/or associated sensors.
The step of detecting may comprise receiving the identifier information from an imaging unit for imaging visual identifier information, for example QR codes, on the one or more microcontroller-sensor systems.
The method may further comprise the step of receiving a trigger signal in response to a power-up of the communications module, or in response to an update message received from one or more repository units, or in response to a new microcontroller- sensor system being detected in the vicinity of the communications module, and performing the detecting step in response to receiving the trigger signal.
According to another embodiment, there is provided a microcontroller-sensor system for use with a communications module as described herein. The microcontroller-sensor system comprises a microcontroller, at least one sensor associated with the microcontroller, and an electronic or visual tag for identifying the microcontroller and/or at least one sensor to the communications module.
Figure 8 shows an example of a wireless network node 800 according to another embodiment, for interfacing between one or more repository units and one or more microcontroller-sensor systems. The wireless network node 800 comprises a processor 801 and a memory 803, said memory 803 containing instructions executable by said processor 801. The wireless network node 800 is operative to: detect one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module; communicate with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems; and communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module.
The first interface module is a type of interface module that is capable of obtaining identifier information relating to one or more MSSs without having specific knowledge of a particular type of communication protocol used by a MSS, e.g. by using a standardised RFID link, with the third interface module then being used to communicate user and/or control plane signalling with the MSS, once the type of MSS has been determined from the identifier information.
The embodiments described herein have the advantage of being capable of being used by different MSSs.
The embodiments can be deployed wirelessly in the field, which can be particularly advantageous for remote sensor deployments (for example in remote areas such as forests, fields, etc.), where wireline communication is impossible. This applies to lifecycle operations, i.e. bootstrapping, updating during operation and decommissioning.
The embodiments described above also have an advantage of enabling the functionality of a MSS to be repurposed during its lifetime.
The embodiments described herein can be used in different configurations. For example, Figures 9A to 9D provide examples of different applications of a communications module 105. Figure 9A relates to an example whereby a communications module 105 is configured to interface between a single microcontroller-sensor system 101 and a plurality of repository units 1 10i to 1 10M. The plurality of repository units 1 10i to 1 10M may contain software or firmware relating to a plurality of sensors (not shown) associated with the MSS 101 , and/or the microcontroller of the MSS 101. In such an example, the communications module 105 may comprise a second interface module 107 as described in the embodiments above. It is noted that, in such embodiments having two or more repository units, a second interface module 107 of the communications module 105 may comprise a single interface module which is capable of communicating with multiple repository units, or two or more separate interface modules for interfacing with two or more repository units.
Figure 9B relates to an example whereby a communications module 105 is configured to interface between a single microcontroller-sensor system 101 and a single repository unit 1 10, whereby the repository unit 1 10 contains software or firmware relating to the MSS 101 , including the microcontroller and/or one or more sensors of the MSS 101 .
Figure 9C relates to an example whereby a communications module 105 is configured to interface between a plurality of microcontroller-sensor systems (MMSs) 1011 to 101 N and a single repository unit 1 10, whereby the repository unit 1 10 contains software or firmware relating to the plurality of MSSs 1011 to 101 N, including the microcontrollers and/or one or more sensors of the MSSs 1011 to 101 N.
Figure 9D relates to an example whereby a communications module 105 is configured to interface between a plurality of microcontroller-sensor systems (MMSs) 1011 to 101 N and a plurality of repository units 1 10i to 1 10M, whereby the plurality of repository units 1 10i to 1 10M contain software or firmware relating to the plurality of MSSs 1011 to 101 N, including the microcontrollers and/or one or more sensors of the MSSs 1011 to 101 N.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A communications module (105) comprising:
a first interface module (106) for interfacing with one or more microcontroller- sensor systems, MSSs, wherein a microcontroller-sensor system comprises a microcontroller and at least one associated sensor; and
a second interface module (107) for interfacing with one or more repository units.
2. A communications module (105) as claimed in claim 1 , wherein the first interface module (106) is adapted to receive identifier information from a microcontroller and/or one or more sensors associated with a microcontroller of a MSS.
3. A communications module (105) as claimed in claim 2, comprising a processing unit for detecting the type of microcontroller and/or the type of one or more sensors associated with the microcontroller, using the received identifier information.
4. A communications module (105) as claimed in claim 2 or 3, wherein the identifier information comprises a model type or a serial number of a microcontroller and/or sensor.
5. A communications module (105) as claimed in any one of claims 1 to 4, wherein the first interface module (106) is adapted to communicate with the one or more microcontrollers and/or one or more associated sensors using wireless communication.
6 A communications module (105) as claimed in claim 5, wherein the wireless communication comprises short-range radio communication, or radio frequency identification, RFID, communication, or near field communication, NFC, or Bluetooth communication.
7. A communications module (105) as claimed in claim 5 or 6, wherein the first interface module (106) comprises an RFID unit for communicating with one or more RFID units located on the one or more microcontrollers and/or associated sensors of the MSSs.
8. A communications module (105) as claimed in claim 7, wherein the RFID unit comprises an RFID reader for communication with one or more passive or active RFID tags located on the one or more microcontrollers and/or associated sensors.
9. A communications module (105) as claimed in any one of claims 1 to 4, wherein the first interface module (106) is coupled to an imaging unit for imaging visual identification tags located on the one or more microcontrollers-sensor systems
10. A communications module (105) as claimed in any one of claims 1 to 9, further comprising a third interface module (108) for communicating configuration and/or update data with the one or more microcontroller-sensor systems.
1 1 . A communications module (105) as claimed in claim 10, wherein the communications module is adapted, in response to a trigger signal, to:
detect one or more microcontroller-sensor systems using the first interface module (106);
communicate with one or more repository units via the second interface module (107) to obtain configuration or update data for the one or more detected microcontroller-sensor systems; and
communicate the obtained configuration or update data to the one or more detected microcontroller-sensor systems using the third interface module (108).
12 A communications module (105) as claimed in claim 1 1 , wherein a trigger signal is received in response to a power-up of the communications module, or in response to an update message received from one or more repository units, or in response to a new microcontroller-sensor system being detected in the vicinity of the communications module.
13 A communications module (105) as claimed in any one of the preceding claims, wherein the second interface module (107) is configured to communicate with one or more repository units over a long-range radio communications link.
14. A method in a communications module (105) for interfacing between one or more repository units and one or more microcontroller-sensor systems, the method comprising:
detecting one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module (step 701 );
communicating with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller-sensor systems (step 703); and
communicating the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module (step 705).
15. A method as claimed in claim 14, wherein the step of detecting comprises receiving identifier information from a microcontroller and/or one or more sensors associated with a microcontroller.
16. A method as claimed in claim 15, wherein prior to the step of communicating with the one or more repository units, the method comprises detecting the type of microcontroller and/or the type of one or more sensors associated with the microcontroller using the received identifier information.
17. A method as claimed in any one of claims 14 to 16, wherein the step of detecting comprises communicating with the one or more microcontroller-sensor systems using short-range radio communication, or radio frequency identification, RFID, communication, or near field communication, NFC, or Bluetooth communication.
18. A method as claimed in claim 17, wherein the step of detecting comprises controlling an RFID reader to communicate with one or more passive or active RFID tags located on one or more microcontrollers and/or associated sensors.
19. A method as claimed in claim 15, wherein the step of detecting comprises receiving the identifier information from an imaging unit for imaging visual identifier information on the one or more microcontroller-sensor systems.
20. A method as claimed in any one of claims 14 to 19, further comprising the step of receiving a trigger signal in response to a power-up of the communications module, or in response to an update message received from the one or more repository units, or in response to a new microcontroller-sensor system being detected in the vicinity of the communications module, and performing the detecting step in response to receiving the trigger signal.
21 . A microcontroller-sensor system for use with a communications module as claimed in any one of claims 1 to 13, comprising:
a microcontroller (102);
at least one sensor (103) associated with the microcontroller; and an electronic or visual tag for identifying the microcontroller and/or at least one sensor to the communications module.
22. A wireless network node (800) for interfacing between one or more repository units and one or more microcontroller-sensor systems, the wireless network node (800) comprising a processor (801 ) and a memory (803), said memory (803) containing instructions executable by said processor (801 ), whereby said wireless network node (800) is operative to:
detect one or more microcontroller-sensor systems in a vicinity of the communications module using a first interface module;
communicate with one or more repository units using a second interface module to obtain configuration and/or update data for the one or more detected microcontroller- sensor systems; and
communicate the obtained configuration and/or update data to the one or more microcontroller-sensor systems using a third interface module.
PCT/EP2016/071436 2016-09-12 2016-09-12 Communications module and method Ceased WO2018046108A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/071436 WO2018046108A1 (en) 2016-09-12 2016-09-12 Communications module and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/071436 WO2018046108A1 (en) 2016-09-12 2016-09-12 Communications module and method

Publications (1)

Publication Number Publication Date
WO2018046108A1 true WO2018046108A1 (en) 2018-03-15

Family

ID=56920709

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/071436 Ceased WO2018046108A1 (en) 2016-09-12 2016-09-12 Communications module and method

Country Status (1)

Country Link
WO (1) WO2018046108A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080150698A1 (en) * 2006-12-26 2008-06-26 G2 Microsystems, Inc. Radio frequency identification tag with passive and active features
EP2741055A2 (en) * 2012-12-07 2014-06-11 General Electric Company Sharing information associated with power generation devices via a file system on a network
WO2016054177A1 (en) * 2014-09-30 2016-04-07 Tego, Inc. Systems and methods for rfid information management

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080150698A1 (en) * 2006-12-26 2008-06-26 G2 Microsystems, Inc. Radio frequency identification tag with passive and active features
EP2741055A2 (en) * 2012-12-07 2014-06-11 General Electric Company Sharing information associated with power generation devices via a file system on a network
WO2016054177A1 (en) * 2014-09-30 2016-04-07 Tego, Inc. Systems and methods for rfid information management

Similar Documents

Publication Publication Date Title
US8677343B2 (en) Centrally coordinated firmware upgrade model across network for minimizing uptime loss and firmware compatibility
US10880404B2 (en) On-vehicle control device and on-vehicle control device information update system
EP2026223B1 (en) Data collection system having EIR terminal interface node
KR101845290B1 (en) Method and device for updating firmware based on a device management command
CN105721555B (en) Operating system and internet-of-things terminal equipment for Internet of Things
US9894146B2 (en) Dynamic lighting system
CN106471468A (en) Wireless device firmware is updated in context
CN112661065A (en) System and method for materials handling vehicle network
CN112256294A (en) Terminal application deployment method, cloud platform, system and storage medium
KR101327680B1 (en) Apparatus, system and method for upgrading firmware of energy device
CN101854623B (en) System and method for remote upgrade of M2M terminal
EP3350962B1 (en) Management of communication between m2m device and m2m server
US10085147B2 (en) Configuring network access parameters
US20150142937A1 (en) Method and system for remote equipment data installation
US20070236345A1 (en) Wireless sensor node executable code request facilitation method and apparatus
KR102685751B1 (en) Smart factory system based on cloud computing
JPH11355867A (en) Communication system and its transmitter
WO2018046108A1 (en) Communications module and method
US20240323257A1 (en) System and method for tag-gateway communications
JP5966664B2 (en) Position information management system, wireless terminal control method, and management server
WO2016200298A1 (en) Method for autonomous operation and maintenance of a sensor network, sensor management system, computer programs and computer program products
KR20140010643A (en) Method for collecting sensing data using portable terminal and apparatus for collecting sensing data
EP2919415B1 (en) Online indication method, apparatus and system
KR20160130622A (en) Method for processing command in low power sensor network
KR20150019152A (en) Method and apparatus for managing firmware

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16763825

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16763825

Country of ref document: EP

Kind code of ref document: A1