(19)
(11)EP 3 353 658 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
19.10.2022 Bulletin 2022/42

(21)Application number: 15904920.4

(22)Date of filing:  25.09.2015
(51)International Patent Classification (IPC): 
G05B 19/042(2006.01)
(52)Cooperative Patent Classification (CPC):
G05B 19/0428; G05B 2219/25166
(86)International application number:
PCT/US2015/052187
(87)International publication number:
WO 2017/052582 (30.03.2017 Gazette  2017/13)

(54)

SENSOR LIFECYCLE MANAGEMENT SYSTEM

SENSORLEBENSZYKLUSVERWALTUNGSSYSTEM

SYSTÈME DE GESTION DE CYCLE DE VIE DE CAPTEUR


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(43)Date of publication of application:
01.08.2018 Bulletin 2018/31

(73)Proprietor: Intel Corporation
Santa Clara, CA 95054 (US)

(72)Inventors:
  • KELLY, Mark
    Leixlip Leixlip Co. (IE)
  • NOLAN, Keith
    Mullingar WH N91 C7W7 (IE)

(74)Representative: Maiwald Patent- und Rechtsanwaltsgesellschaft mbH 
Elisenhof Elisenstraße 3
80335 München
80335 München (DE)


(56)References cited: : 
EP-A1- 2 573 742
GB-A- 2 513 976
US-A1- 2008 219 520
US-A1- 2012 105 214
US-B1- 7 197 370
CN-A- 102 868 972
US-A- 5 939 609
US-A1- 2012 089 369
US-A1- 2013 276 144
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    FIELD



    [0001] The present disclosure relates to a system, in particular to, a sensor lifecycle management system.

    BACKGROUND



    [0002] A sensor array may include a plurality of sensors, with each sensor positioned at a respective location. One or more of the respective sensor locations may be adj acent each other and/or one or more of the sensor locations may be distant from one another. Sensor arrays may be configured to monitor a wide array of parameters in sectors that include environmental, industrial, residential, military and health sectors. For example, parameters may include, but are not limited to, weather conditions, air quality, household goods, stock inventory, and equipment and tools. The monitoring, and thus the sensors, may be spread across wide geographical areas. For example, at least some Internet of Things (IoT) deployments may include one or more sensor array(s).

    [0003] US 2012/0105214 A1 describes an aggregating and routing sensor data at a community sensor-coordinating entity. The method comprises receiving sensor data from multiple sensors associated with multiple persons; for each of the sensors, identifying the person associated with the sensor; determining whether the sensor data are valid; and, for the sensor data that are valid, aggregating them based on the associations of their sensors with the persons and routing them to one or more sensor-application service provides based on associations of the persons with the sensor-application-service providers.

    [0004] GB 2 513 976 A describes a system for authenticating data acquired by a network of multiple sensors prior to storing the data in a database and providing an authenticated presentation of the data. The multiple sensors are authenticated as well as the data they provide, the system also authenticates users requesting data access and authenticates analysts or intelligence agents that provide analyses of data stored in the database.

    [0005] US 5 939 609 A describes a multi-use sensor having a controllable number of measurement cycles. The multi-use sensor consists of a sensor and/or electrodes that are encased in a suitable material to allow reuse of the sensor and sensor life cycle circuitry that functions to regulate the number of operational cycles that the sensor can execute to ensure that the multi-use sensor is not used beyond its effective life.

    [0006] US 2013/0276144 A1 describes a system for authenticating data acquired by multiple sensors prior to storing the data in a database. The system also authenticates users requesting data access and intelligence agents that provide analysis of data stored in the database. An apparatus according to the invention is defined in claim 1. The dependent claims define advantageous embodiments.

    BRIEF DESCRIPTION OF DRAWINGS



    [0007] Features and advantages of the claimed subject matter Will be apparent from the following detailed description of embodiments consistent therewith, which description should be considered with reference to the accompanying drawings, wherein:

    FIG. 1 illustrates a functional block diagram of a system, including a sensor lifecycle management system consistent with several embodiments of the present disclosure;

    FIG. 2 is a flowchart of example sensor lifecycle management operations according to various embodiments of the present disclosure;

    FIG. 3 illustrates a sequence of example sensor lifecycle management operations consistent with several embodiments of the present disclosure;

    FIG. 4 illustrates a sequence of example sensor enumeration operations according to various embodiments of the present disclosure;

    FIG. 5 illustrates a sequence of example sensor report operations according to various embodiments of the present disclosure; and

    FIG. 6 illustrates a sequence of example sensor report operations according to one embodiment of the present disclosure.


    DETAILED DESCRIPTION



    [0008] Operationally, sensors may have a limited lifespan. Typically, vendor-specific methods are utilized to configure one or more sensor(s) and to connect the sensor(s) to a host system configured to receive sensor data. Thus, a customized interface may be required in order to couple to each sensor. Sensors may fail and/or may suffer from faults that may or may not be visible to the host system. In other words, a faulty sensor may continue to provide data even though the data is erroneous. The host system that receives the erroneous data may rely on the data, not recognizing that the data is erroneous. Further, the host system may be unaware that a sensor has been coupled to the host system unless there is action by a user, i.e., a system administrator, that informs the host system. The host system may be further configured to poll the sensor to read data that may or may not be available. In other words, a sensor with data to report may have to wait to report the data, a sensor that isn't ready may provide erroneous data or a sensor without data to report may be polled thereby increasing communication overhead.

    [0009] Generally, this disclosure relates to a sensor lifecycle management system. An apparatus, method and/or system are configured to manage a respective lifecycle of each of a plurality of sensors. A sensor lifecycle begins with an initial deployment of the sensor, continues through the life of the sensor and ends with the permanent removal, i.e., retirement, of the sensor. Each sensor is configured to provide enumeration information (i.e., enumeration data), e.g., at power up, and lifecycle information (i.e., lifecycle data) during its respective lifecycle. Enumeration information includes details related to the identity of the sensor and/or one or more sensor operational characteristic(s). Lifecycle information includes indicators related to the status, i.e., state, of the sensor (e.g., unknown, ready, not available, no data, initializing, access denied and/or error).

    [0010] A sensor module, consistent with the present disclosure, includes a sensor controller and a sensor. The sensor controller is configured to enumerate the sensor module and/or the sensor to a sensor processing unit. The sensor controller is further configured to monitor operation of the sensor and to provide sensor lifecycle information to the sensor processing unit over the lifecycle of the sensor. The sensor is configured to capture measurement data corresponding to a value of an environmental parameter and to provide an electrical signal as output (i.e., sensor data) that is related to the measurement data. The sensor controller is configured to receive the sensor data and to report associated sensor data to the sensor processing unit.

    [0011] The sensor controller is configured to enumerate the sensor module in response to powering on. For example, the sensor controller may be configured to inform the sensor processing unit and/or a host system that it has been connected and what type of sensor it is. The sensor controller may be further configured to inform the sensor processing unit that it is preparing to make observations, and that it is has performed a sensor reading and is ready to dispatch its sensor data. The sensor data may be processed by the sensor controller prior to dispatch. For example, the sensor data may be averaged, i.e., smoothed, prior to dispatch.

    [0012] The sensor controller is configured to utilize a communication protocol configured to enable the sensor controller to communicate enumeration data, lifecycle data and/or sensor data to the sensor processing unit. The communication protocol may comply and/or be compatible with a USB (Universal Serial Bus) HID (Human Interface Device) protocol, as described herein. A communications link between a sensor module and a sensor processing unit may comply and/or be compatible with one or more serial communications protocols, e.g., an I2C (Inter-integrated circuit) serial communication protocol, as described herein, and/or variant(s) thereof. Compatibility with the USB HID protocol and the I2C protocol is configured to facilitate integration into IoT sensor-based devices and applications.

    [0013] Thus, operation of one or more sensor arrays may be facilitated. Previously unknown sensors and/or sensor modules may be coupled to a host system and, through enumeration, may be recognized. Further, sensor operation may be monitored throughout the deployment period thus avoiding inappropriate action based on erroneous data. For example, a gradual decline in effectiveness and/or a sensor breach of known-good limits (e.g., overgassing, sensor membrane saturation) may be detected and communicated. A sensor module may be further configured to perform configurable processing on raw sensor observations (e.g., smoothing, automatic re-zeroing to ensure correct operation in unattended deployment scenarios).

    [0014] A lifecycle management system, consistent with the present disclosure, is configured to allow a sensor module and associated sensor to proceed from initial power-on to a normal sensor observation data gathering phase. The sensor modules are configured to report lifecycle information including, for example, state and error information to a sensor application, thus, enabling the sensor application to take action, e.g., reset a sensor, decommission the sensor, and/or alert a user.

    [0015] FIG. 1 illustrates a functional block diagram of a system 100, including a sensor lifecycle management system 101 consistent with several embodiments of the present disclosure. The system 100 includes the sensor lifecycle management system 101 and may further include a host system 108. Sensor lifecycle management system 101 includes a sensor processing unit 102, a sensor interface 104 and a plurality of sensor modules 106A, 106B,..., 106n, e.g., sensor module 106A. In the following, although sensor module 106A is described, such description applies equally to sensor modules106A, 106B,..., 106n. Thus, reference to sensor module 106A may be understood as referring to any of sensor modules 106A, 106B,..., 106n.

    [0016] The host system 108 may include a user interface (UI) 142. The host system 108 is configured to receive enumeration information, lifecycle information and sensor data from one or more sensor processing units, e.g., sensor processing unit 102. The host system 108 and/or sensor processing unit 102 may be configured to display the received information and data using UI 142 and/or may be configured to receive user input via UI 142. The user interface 142 may thus include, but is not limited to, a display (e.g., a touch sensitive display), a keypad, a keyboard, a mouse, etc.

    [0017] The sensor processing unit 102 includes a processor 110, a memory 112 and a communication interface 114 and may include a sensor application 116. Sensor processing unit 102 and, e.g., sensor application 116, may be configured to provide enumeration information, lifecycle information and sensor data to host system 108. The enumeration information, lifecycle information and sensor data may be formatted to facilitate ease of viewing by a user. For example, enumeration information, lifecycle information and/or sensor data for a plurality of sensors may be provided to a user, e.g., displayed on UI 142, in a table format. In another example, sensor data may be converted to a scientific notation number format, e.g., to facilitate user understanding.

    [0018] Enumeration information (i.e., enumeration data) may include, but is not limited to, a sensor name, a sensor manufacturer name, a sensor serial number, a hardware version, a firmware version, and/or one or more sensor characteristics. Sensor characteristics may include, but are not limited to, information related to a type of sensor reading (e.g., provides parts per billion readings), whether the sensor requires a warm-up time, a frequency at which a sensor captures data (i.e., the frequency at which a sensor takes a reading), and/or whether sensor data is to be reported when available or at preset time intervals.

    [0019] Lifecycle information may include, but is not limited to, the sensor identifier, e.g., the sensor name, and a sensor status indicator. Sensor status indicators include, but are not limited to, state unknown, ready, not available, no data, initializing, access denied and error. For example, sensor status ready is configured to indicate that the sensor module is ready to dispatch sensor observation information, i.e., sensor data. In another example, sensor error is configured to indicate that the sensor has encountered an error and/or fault state.

    [0020] Processor 110 may include, but is not limited to, a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), application specific instruction processor (ASIP), etc. Memory 112 may be configured to store sensor application 116 and/or enumeration information, lifecycle information and/or sensor data for one or more of a plurality of sensors and/or a plurality of sensor modules.

    [0021] Communication interface 114 may comply and/or be compatible with one or more, wired and/or wireless, communication protocols. Communication interface 114 is configured to couple sensor processing unit 102 to host system 108. Communication interface 114 may be further configured to couple sensor processing unit 102 to sensor interface 104 via communication link 103. The communication interface 114 and/or communication link 103 may be configured to comply and/or be compatible with a serial communication protocol. For example, the serial communication protocol may correspond to an I2C communication protocol or an SPI communication protocol, as described herein. Communication link 103 may be configured to carry one or more frames that may comply and/or are compatible with a USB HID protocol, as described herein. Each frame may include, for example, control information (e.g., start bit, stop bit, etc.) and a payload that contains enumeration information, lifecycle information and/or sensor data.

    [0022] Sensor interface 104 is configured to couple sensor processing unit 102 to a plurality of sensor modules 106A, 106B,..., 106n, e.g., sensor module 106A. Sensor interface 104 may include a multiplexer MUX 144 and an Input/Output (I/O) Expander 145. Sensor processing unit 102 and, e.g., sensor application 116, may be configured to control MUX 144 to select one sensor module, e.g., sensor module 106A, of the plurality of sensor modules 106A, 106B,..., 106n for communication operations. For example, sensor processing unit 102 may be configured to control MUX 144 by selecting a MUX channel corresponding to an address associated with the selected sensor module. The address may correspond to a slot in sensor interface 104 configured to receive a sensor module, e.g., sensor module 106A. As used herein, a slot corresponds to a connector and/or a port configured to receive a sensor module. The address may be determined, for example, by reading a stored value from the I/O expander 145 via communications link 103. Each binary value in this stored value is associated with a sensor slot. The sensor module address may then be determined via a lookup table using the bitfield information contained in the information retrieved from the IO expander 145. The selected sensor module 106A, may then be coupled to sensor processing unit 102 via communication links 103, 107 and MUX 144.

    [0023] The I/O expander, e.g., I/O expander 145 is configured to connect to the sensor interrupt lines, that may be included in communication link 107. The I/O expander is configured to read to determine which sensor module(s) have asserted an interrupt, i.e., which sensor modules are signaling that they require attention. The MUX, e.g., MUX 144, is configured to communicate with the sensors, i.e., sensor modules 106A, 106B,..., 106n, via communication link 107. The communication may comply and/or be compatible with the I2C protocol, as described herein. The MUX is configured to provide a 1:N mapping between sensor modules and sensor interface 104. In other words, a single I2C input channel and N I2C output channels configured to support at least N sensors. Thus, in order to address a specific sensor, the channel that the desired sensor is connected to may be selected.

    [0024] Sensor module 106A includes a sensor controller 120 and at least one sensor, e.g., sensor 122. Sensor controller 120 includes a processor 130, memory 132 and a communication interface 134. Sensor controller 120 is configured to capture sensor data from sensor 122. As used herein, sensor data corresponds to an output from a sensor related to measurement data, i.e., related to a sensed environmental parameter value. Sensor data may include one or more voltage values and/or one or more current values. For example, sensor 122 may correspond to and/or may include a transducer configured to convert measurement data into an electrical value, e.g., sensor data.

    [0025] Memory 132 may be configured to store sensor logic 136 and data store 138. Data store 138 is configured to contain enumeration information (i.e., enumeration data), lifecycle information (i.e., lifecycle data) and sensor data. Processor 130 and/or sensor controller 120 may include, but are not limited to, a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), application specific instruction processor (ASIP), etc. For example, a sensor controller 120 that includes processor 130, memory 132 and communication interface 134 may correspond to a microcontroller. Sensor controller 120 may further include interface circuitry, e.g., an analog-to-digital converter (ADC), configured to facilitate capturing, receiving and or acquiring sensor data from sensor 122.

    [0026] Communication interface 134 may be further configured to couple sensor module 106A to the sensor interface 104 via communication link 107. For example, communication interface 134 and/or communication link 107 may comply and/or be compatible with a serial, i.e., I2C, communication protocol, as described herein.

    [0027] Sensor controller 120 and/or sensor logic 136 may be configured to capture sensor data and may be further configured to store a representation (e.g., a corresponding digital value) of captured sensor data to data store 138. Sensor logic 136 is further configured to manage communication between sensor module 106A, sensor interface 104 and ultimately sensor processing unit 102. For example, sensor logic 136 may be configured to receive commands, queries, requests and/or data from, e.g., sensor application 116, via sensor interface 104. In another example, sensor logic 136 may be configured to control communication interface 134 to transmit interrupts, enumeration information, lifecycle information, and/or sensor data to sensor interface 104 and/or sensor processing unit 102, e.g., to sensor application 116.

    [0028] Communication between sensor processing unit 102, sensor interface 104 and sensor module 106A via communication links 103, 107 may comply and/or may be compatible with a USB HID communication protocol, as described herein. Information and data communicated may be organized into one or more frames, that each includes a payload. The information and data included in each payload may be contained in a descriptor that is organized according to a corresponding byte frame format, e.g., a byte address field format. Each frame includes a sequence of bytes. Each byte frame format may define a plurality of fields with each field corresponding to one or more bit(s) in a byte and/or one or more byte(s). Thus, each field may have an associated defined position in the frame (indicated by the byte address field), a defined size (i.e., a length in bits or bytes) and may be configured to contain defined, i.e., specified, information and/or data. Each byte frame format may provide an associated defined format for a corresponding descriptor and/or a corresponding report (e.g., descriptor byte frame, report frame). A corresponding descriptor and/or corresponding report may then be formatted according to the field definitions included in the byte frame format. Thus, each descriptor and/or associated byte frame format is configured to facilitate communication of information and/or data between sensor module 106A and sensor processing unit 102 and/or sensor interface 104. The format of the descriptor may be configured to comply and/or be compatible with the USB HID communication protocol.

    [0029] Each frame may also have an associated defined format configured to facilitate communication between sensor processing unit 102, sensor interface 104 and sensor module 106A. The format of the frame may be configured to comply and/or be compatible with an I2C communication protocol. For example, in addition to the payload (i.e., the data), the byte frame format may include a read or write operation byte, start bit(s), stop bit(s) and/or address bits.

    [0030] In operation, one or more of sensor modules 106A, 106B,..., 106n, e.g., sensor module 106A, may be coupled to sensor interface 104. As a result of the coupling and/or in response to a command from, for example, sensor application 116, power may be applied to sensor module 106A via communication link 107. A discovery process may then proceed between sensor processing unit 102 and sensor module 106A. A successful discovery process may then include, and/or be followed by, an enumeration phase. The enumeration phase may then be followed by a lifecycle phase, i.e., a reporting phase. The discovery process is configured to alert sensor processing unit 102 that sensor module 106A and/or other sensor modules are coupled to sensor interface 104. The discovery phase may further include determining an associated address for each powered on sensor module. The enumeration phase is configured to identify each sensor module that is coupled to sensor interface 104 and is powered up. Communication between a sensor module, e.g., sensor module 106A, and sensor processing unit 102 may generally be initiated via assertion of an interrupt by sensor module 106A. Sensor processing unit 102 and/or sensor interface 104 may then be configured to handle the interrupt. Thus, asserting an interrupt is configured to alert the sensor processing unit 102 of the presence of sensor module 106A and/or of any pending state changes of sensor module 106A.

    [0031] Sensor module 106A may be configured to assert an interrupt, e.g., in response to being powered up. Asserting the interrupt is configured to announce the presence of sensor module 106A. In some embodiments, the sensor module may be configured to determine an associated address (i.e., self address resolution) in response to powering on. In response to the interrupt assertion, sensor module 106A may receive a request for an enumeration descriptor, e.g., an HID descriptor. For example, the HID descriptor may be requested by sensor processing unit 102. Table 1 illustrates one example byte frame format for the HID descriptor request descriptor.
    Table 1
    ByteFieldValue
    1 Request Length 0x04
    2 HID Usage ID 0xF5
    3 Random Seed 0xAB
    4 CRC Byte 0xXX


    [0032] As illustrated in Table 1, the byte frame format for the HID descriptor request includes four fields and each field has length one byte. The first field is configured to contain the request length, four bytes in this example. The second field is configured to contain an HID usage identifier. The HID usage identifier is configured to denote the type of operation requested. For example, 0xF5 corresponds to a HID descriptor read request. The third field is configured to contain a random seed that may be utilized to authenticate sensor module 106A, as described herein. The fourth field is a cyclic redundancy check (CRC) for the HID descriptor request. The value of the CRC byte is related to the values of the first, second, and third bytes. Generally, the CRC byte is the nth byte in an n byte frame and is determined as an exclusive-OR of the preceding n-1 bytes in the frame.

    [0033] An enumeration descriptor, e.g., HID descriptor, may be provided by sensor module 106A, e.g., sensor controller 120, in response to the request for the HID descriptor. The HID descriptor is configured to provide enumeration information related to sensor module 106A and/or sensor 122 to sensor processing unit 102. Table 2 illustrates one example byte address field format for an HID descriptor, e.g., an initial sensor description report format. The enumeration descriptor may include a fixed part and a variable part. The fixed part may have a fixed length and the variable part may have a variable length.
    Table 2
    IdentifierByte OffsetNumber of BytesDescription 
    Number of Sensors 1 1 Number of physical sensors in a sensor HUB Fixed Part
    Authentication Key 2 2 Authentication Key
    HID Protocol Version 4 1 Version of the HID Protocol
    Report Descriptor Length 5 2 Report Descriptor Length
    HID Descriptor Length 7 1 Total size of the HID descriptor
    Sensor Name 8 8 String containing Name of the sensor
    Manufacturer 16 6 String containing name of sensor manufacturer
    Serial Number 22 6 Serial number of the sensor Variable Part
    Hardware Version 28 2 Sensor module hardware version
    Firmware Version 30 2 Firmware version of the sensor firmware
    CRC byte 32 1 XOR of all of the above bytes


    [0034] The HID descriptor is configured to provide information related to sensor module 106A and to facilitate communication of lifecycle information from sensor module 106A, e.g., during the lifecycle phase. As illustrated in Table 2, the initial sensor description report (i.e., enumeration descriptor) includes a plurality of ordered fields configured to communicate enumeration information. The enumeration information may be grouped into a fixed part and a variable part. The fixed part may include a number of sensors in a sensor hub, an authentication key, an HID protocol version and a report descriptor length. A sensor hub is an interface that is configured to allow a plurality of sensors (i.e., sensor modules) to be accessed via a single sensor slot in order to extend the number of sensors that may be connected to and supported by, e.g., sensor processing unit 102 and sensor interface 104. The variable part may include an HID descriptor length, a sensor name, manufacturer, a serial number, a hardware version and a firmware version for each of the number of the sensors obtained from the number of sensors field in the fixed part of the frame. For more than one sensor, the variable part of the frame may be extended by concatenating sensor enumeration frame information for each sensor.

    [0035] For example, for a single sensor, the byte address field format for an HID descriptor includes one fixed frame part and one variable frame part. In another example, for two sensors, the byte address field format for an HID descriptor includes one fixed frame part and two variable parts, one variable part for each sensor. The second variable frame part that corresponds to the second sensor is appended to the first variable frame part. Thus, for N sensors, the HID descriptor may then include: Fixed Frame Part | Variable Part 1 | Variable Part 2| ... | Variable Part N, where I corresponds to append.

    [0036] As illustrated by Table 2, the HID descriptor includes a plurality of fields with a respective position in the descriptor defined by a byte offset, and a size of each field defined by a number of bytes. Table 2 further illustrates an identifier associated with each field, a description associated with each field and an indication whether the field lengths are fixed or variable. A first field has length one byte and is configured to contain the number of sensors, i.e., the number of sensors available in the sensor hub. A second field has length two bytes and is configured to contain the authentication key. The authentication key is a result of an exclusive-OR operation between the random seed provided in the HID descriptor request and the lower two bytes of the sensor serial number. The third field has length one byte and is configured to contain the HID protocol version. The fourth field has length two bytes and is configured to contain a report descriptor length and the fifth field has length one byte and is configured to contain the HID descriptor length. The report descriptor length and the HID descriptor length are configured to support a difference in length between the two types of descriptors. The sixth field has length eight bytes is configured to contain an ASCII (American Standard Code for Information Interchange) string (of up to eight characters) that corresponds to the name of the sensor. Based on the type of sensor, the sensor name ASCII string may include, but is not limited to, TEMPERAT, HUMIDITY, LIGHT, SOUND, CO, NO, NO2, SO2, ETO, PM2P5 or PM10. Thus, TEMPERAT corresponds to a temperature sensor, HUMIDITY corresponds to a humidity sensor, LIGHT corresponds to a light sensor, SOUND corresponds to a sound to sensor, CO corresponds to a carbon monoxide sensor, NO corresponds to a nitrous oxide sensor, NO2 corresponds to a nitrous dioxide sensor, SO2 corresponds to a sulfur dioxide sensor, ETO corresponds to an Ethylene Oxide sensor, PM2P5 corresponds to a particulate matter sensor for particulate above 2.5 micrometers and PM10 corresponds to a particulate matter sensor for particulate above 10 micrometers.

    [0037] The seventh field has length six bytes and is configured to contain an ASCII string corresponding to the name of the sensor manufacturer. The eighth field has length six bytes and is configured to contain the serial number of the sensor. The ninth field has length two bytes and is configured to contain the hardware version. For example, the hardware version may correspond to 0x01 and 0x00, where 0x corresponds to hexadecimal. The tenth field has length two bytes and is configured to contain firmware version, e.g., 0x09. The last field has length one byte and is configured to contain a CRC byte. For example, the CRC byte may contain an exclusive-OR result of the contents of fields one through ten.

    [0038] Thus, the HID descriptor response is configured to enumerate an associated sensor and/or sensor module, e.g., sensor 122 and/or sensor module 106A, as well as provide descriptor, hardware, and firmware information.

    [0039] Sensor processing unit 102 may then be configured to authenticate sensor module 106A utilizing the received HID descriptor. For example, module 106A may perform an XOR (i.e., exclusive-OR) operation using the random seed bytes sent as part of the HID descriptor request with two bytes of the sensor serial number. The results may then be included in the authentication field of the HID descriptor. A sensor application, e.g., sensor application 116, may then perform authentication by performing a similar XOR operation using the serial number bytes obtained from the sensor and the original random seed bytes. If a match between the two different calculations is achieved, the sensor is deemed to be authenticated and is then permitted to commence normal operation. If the authentication attempt fails, sensor module 106A may not be allowed to operate. For example, power may be removed from the sensor module 106A.

    [0040] Sensor processing unit 102, e.g., sensor application 116, may then provide a request for a report descriptor to sensor module 106A. Table 3 is one example byte frame format for a report request descriptor.
    Table 3
    ByteFieldValue
    1 Request Length 0x02
    2 Report Descriptor Usage ID (e.g., 0xFA) 0xFA
    3 CRC Byte (XOR of all the above Bytes) 0xF8


    [0041] As illustrated in Table 3, the byte frame format for a report descriptor request frame may include three fields with each field having a length of one byte. The first field is configured to contain a length of the report descriptor request. The second field is configured to contain the report descriptor usage identifier, e.g.,0xFA, and the third field is configured to contain the CRC byte for the report descriptor request.

    [0042] Sensor module 106A may then be configured to provide a report descriptor (i.e., HID report descriptor) in response to the request for the report descriptor. Table 4 illustrates a report descriptor byte frame format.
    Table 4
    ByteFieldValue
    1 to 2 Report Descriptor Length 0x00XX
    3 to n Report Descriptor Information variable
    N+1 CRC Byte (XOR of all the above Bytes) 0xYY


    [0043] The HID report descriptor includes three fields and may include a plurality of bytes. For example, the first field has a length of two bytes and is configured to contain the report descriptor length. The second field is configured to contain the report descriptor information and is of variable length. The last field has length of one byte and is configured to contain the CRC byte. The report descriptor information is sensor-specific. In other words, the information included in the report descriptor information field and the associated values are related to the sensor and associated sensor characteristics. For example, the report descriptor information may vary with one or more of sensor name, sensor manufacturer, sensor serial number, sensor module hardware version and/or sensor module firmware version. The report descriptor information may include sensor metadata, e.g., report size, report count, minimum sensor value, maximum sensor value, minimum reporting interval, sensor manufacturer, sensor model, sensor serial number, sensor description, sensor unique ID, human-readable sensor name, etc. The CRC checksum byte is configured to indicate that a correct frame has been received.

    [0044] Once the report descriptor has been provided, the enumeration phase may be complete. The sensor module 106A may then be configured to determine the associated sensor 122 state and to communicate, i.e. report, the sensor state to the sensor processing unit 102.

    [0045] Table 5 illustrates one example report byte frame format and byte fields for a lifecycle report descriptor. The lifecycle report descriptor may include one or more report(s). For example, a sensor hub device that includes, e.g., four different sensors in a single package, may produce four reports with one report for each of the sensors.
    Table 5
    Byte\Bit76543210
    1 Number of Reports Operation Type Report Type
    2 Length
    3 Report ID (Specific to each sensor)
    4 to 5 Sensor State Usage ID (common to all sensors)
    6 to 7 Actual Sensor State


    [0046] The lifecycle report descriptor includes both byte length fields and bit length fields. For example, the lifecycle report descriptor may include seven bytes and seven fields. The first byte includes three fields and includes two bits corresponding to report type, two bits corresponding to operation type and three bits corresponding to the number of reports. The fourth field that has length one byte is configured to contain report descriptor length. The fifth field that has length one byte is configured to contain a report identifier that is specific to each sensor. The sixth field includes bytes four and five and contain a sensor state usage identifier that may be common to a plurality of sensors. The sensor state usage identifier is configured to denote a sensor state report. The seventh field includes bytes six and seven and contains an actual sensor state.

    [0047] Table 6 illustrates example report identifiers associated with each sensor. The report identifiers may be contained in the fifth field, third byte of the report descriptor illustrated in Table 5. The report identifiers are two digit hexadecimal numbers and each hexadecimal number corresponds to a sensor type. Some sensor types, e.g., CO2, may have more than one corresponding report ID. Thus, up to 255 sensors may be identified, i.e., 0x00 is typically not used as a report identifier (ID).
    Table 6
    SensorReport ID
    CO 0x11
    SO2 0x14
    NO2 0x17
    NOx 0x1A
    CO2 0x01, 0x02, 0x03
    NO2 0x04, 0x05, 0x06
    PM2.5 0x2A, 0x2B, 0x2C
    PM10 0x2D, 0x2E, 0x2F
    Temp 0x3A
    Humidity 0x3D
    Sound 0x41
    Light 0x47
    ETO 0x21


    [0048] Thus, each sensor is configured to have an associated report identifier. The sensor state definition usage identifier may contain the value 0x0201 that is constant for all sensors indicating that the report is a sensor state report.

    [0049] Table 7 illustrates example sensor states associated with each sensor and/or sensor module, e.g., sensor 122 and/or sensor module 106A. Sensor state indicators may be included in the seventh field, sixth and seventh bytes of the report descriptor illustrated in Table 5. The sensor state indicators are four digit hexadecimal numbers and each hexadecimal number corresponds to a respective sensor state.
    Table 7
    Sensor StateValue
    Sensor State: Undefined/Unknown 0x0800
    Sensor State: Ready 0x0801
    Sensor State: Not Available 0x0802
    Sensor State: No Data 0x0803
    Sensor State: Initializing 0x0804
    Sensor State: Access Denied 0x0805
    Sensor State: Error 0x0806


    [0050] The sensor states include, but are not limited to, undefined (and/or unknown), ready (i.e., ready to present data to an application), not available (i.e., is not ready to present data to the application), no data (i.e., no data available to be presented to the application), initializing (i.e., sensor is warming up following a power-on) and access denied (i.e., sensor is preventing access to the measurement data). Ready corresponds to a sensor and/or sensor module that are ready to present measurement data and/or sensor data to an application.

    [0051] Upon completion of the initial enumeration, the sensor module 106a may be configured to communicate (i.e., report) the sensor state to the sensor processing unit 102. If the sensor state corresponds to error, the sensor module 106A may report (i.e. communicate) an error report to sensor processing unit 102 and sensor application 116.

    [0052] If the sensor state corresponds to ready, the sensor module 106A may then be configured to report (i.e., communicate) the sensor data. The sensor data may be communicated to the sensor processing unit 102. For example, the sensor module 106A may be configured to communicate the sensor data at predefined and/or possibly preconfigured report intervals. In another example, sensor module 106A may be configured to provide sensor data whenever the sensor data is available. In other words, in this example, durations of time intervals between reports may vary.

    [0053] Table 8 illustrates one example of a sensor data report byte frame format. The sensor data report byte frame format illustrated in Table 8 is similar to the report byte frame format and byte fields for a lifecycle report descriptor illustrated in Table 5 with the exception of fields six (i.e., bytes 4 to 5) and seven (i.e., bytes 6 to 10).
    Table 8
    Byte\Bit76543210
    1 Number of Reports Operation Type Report Type
    2 Length
    3 Report ID (Specific to each sensor)
    4 to 5 Data field usage ID (Specific to each sensor)
    6 to 10 Sensor data in IEEE 754 single precision binary floating-point format


    [0054] Field six of the sensor state report byte frame format illustrated in Table 5 is configured to contain a sensor state usage identifier common to all sensors. Field six of the sensor data report byte frame format illustrated in Table 8 is configured to contain a data field usage identifier specific to each sensor. Field seven of the sensor state report byte frame format illustrated in Table 5 is configured to contain a sensor state indicator and field seven of the sensor data report byte frame format illustrated in Table 8 is configured to contain four bytes of sensor data in IEEE 754 single-precision binary floating-point format.

    [0055] Table 9 illustrates data field usage identifiers for a range of sensors. In particular, sensor data field usage identifiers may be included in the fourth and fifth bytes and sensor data may be included in bytes 6 through 9 of an HID report frame.
    Table 9
    ByteFieldValue
    1 Number of Reports, Operation Type & Report Type 0x19
    2 Length 0x08
    3 Report ID (The following values will be observed depending on type of sensor) 0x11 or 0x12 or 0x13
       
    CO Sensor 0x11
    SO2 Sensor 0x14
    NO2 Sensor 0x17
    NOx Sensor 0x1A
    CO2 Sensor 0x01-0x03
    N02 Sensor 0x04-0x06
    PM2.5 Sensor 0x2A-0x2C
    PM10 Sensor 0x2D-0x2F
    Temp Sensor 0x3A
    Humidity Sensor 0x3D
    Sound Sensor 0x41
    Light Sensor 0x47
    ETO 0x21
    4 & 5 Sensor Data Field Usage ID (Specific sensors) 0xF301
       
    CO Sensor 0xF301
    SO2 Sensor 0xF306
    NO2 Sensor 0xF311
    NO Sensor 0xF316
    PM2.5 Sensor 0xF501
    PM10 Sensor 0xF506
    Temp Sensor 0x0434
    Humidity Sensor 0x0433
    Sound Sensor 0x0437
    Light Sensor 0x04D1
    ETO 0xF321
    6 - 9 Measured sensor data 0xYYYYYYYY
    10 CRC Byte (XOR of all the above Bytes) 0xXX


    [0056] The sensor module 106A may be further configured to communicate (i.e., report) a change in sensor state to sensor processing unit 102. Reporting a change in sensor state is configured to facilitate lifecycle management operations of sensor processing unit 102. For example, sensor processing unit 102 may be configured to power cycle a sensor module, e.g., sensor module 106A, if a provided sensor state corresponds to an error.

    [0057] Table 10 illustrates operation type specifiers. The operation type corresponds to the second field, i.e., Operation Type, included in the sensor state byte frame format of Table 5 and sensor data report frame of Table 8. A Set operation corresponds to a sensor processing unit to sensor module transaction. A Get operation corresponds to a sensor module, e.g., sensor module106A, to sensor processing unit, e.g., sensor processing unit 102, transaction. Data from a sensor module to a sensor processing unit and associated application (e.g., sensor processing unit 102 and sensor application 116) is a GET request and data from the application to a sensor module is a SET request.
    Table 10
    Operation Type
    ValueOperation
    00 Reserved
    01 Set Request
    10 Get Request
    11 Reserved


    [0058] Table 11 illustrates an example of a GET request byte frame format. The number of reports, e.g., one, operation type, e.g., GET, and report type, e.g., input report, are combined using a logical OR operation to form the first byte of the GET request frame.

    [0059] A SET request frame uses the same byte frame format. The number of reports, e.g. one, operation type, e.g., SET, and report type, e.g., output report, may be combined using a logical OR operation to form the first byte of the SET request frame.
    Table 11
    Byte/Bit76543210
    1 Number of Reports Operation Type Report Type
    2 Length
    3 Report ID (Specific to each sensor)
    4 Sensor Property usage ID (Specific to each sensor property


    [0060] Table 12 illustrates report type specifiers. The report type corresponds to the first field, i.e., report type, included in the sensor state and sensor data report byte frame formats. An input report type corresponds to a report that includes sensor data and/or sensor status, including an error state. A feature report type corresponds to a get request or a set request related to one or more properties of sensor module 106A and or sensor 122. An example of a property may include a sensor reporting interval, i.e., the time interval between sensor measurements. An example of a property change operation may include reducing the time interval between reports from one minute to thirty seconds via a SET request. An output report type corresponds to a report utilized by the sensor processing unit 102, e.g., sensor application 116, for actuation purposes. For example, actuation may include switching an external control entity on or off, adjusting a valve setting, etc.
    Table 12
    Report Type
    ValueReport Type
    00 Not Used
    01 Input Report
    10 Output Report
    11 Feature Report


    [0061] In some embodiments, support for other sensor and/or actuator functionality may be provided. For example, the operation type bytes may be utilized to support other sensor and/or actuator functionality including, but not limited to, switching external power supplies, adjusting the orientation of a movable sensor, e.g. adjust the azimuth and/or elevation of a sensor.

    [0062] Thus, an apparatus, method and/or system are configured to manage a respective lifecycle of each of a plurality of sensors. Each sensor module is configured to provide enumeration data, e.g., at power up, and lifecycle data during its respective lifecycle. A sensor module, consistent with the present disclosure, includes a sensor controller and a sensor. The sensor controller is configured to enumerate the sensor module and/or the sensor to a sensor processing unit. The sensor controller is further configured to monitor operation of the sensor and to provide sensor lifecycle information to the sensor processing unit over the lifecycle of the sensor. The sensor is configured to capture measurement data corresponding to a value of an environmental parameter and to provide an electrical signal as output (i.e., sensor data) that is related to the measurement data. The sensor controller is configured to receive the sensor data and to report associated sensor data to the sensor processing unit. The sensor processing unit may then be configured to manage the lifecycle of each associated sensor.

    [0063] FIG. 2 is a flowchart 200 of lifecycle management operations according to various embodiments of the present disclosure. In particular, the flowchart 200 illustrates discovery, enumeration, status monitoring and reporting and data reporting for a sensor, e.g., sensor 122 of sensor module 106A. The operations may be performed, for example, by sensor modules 106A, 106B,..., and/or 106n of FIG. 1.

    [0064] Operations of this embodiment begin with operation 202 power on. For example, a sensor module, e.g., sensor module 106A, is powered on. A presence of a sensor module is announced at operation 204. For example, announcing may include asserting an interrupt. A request for an HID descriptor may be received at operation 206. Operation 208 may include providing an HID descriptor. For example, the request for the HID descriptor may be received from, and the HID descriptor may be provided to, a sensor processing unit, e.g., sensor processing unit 102. Whether an authentication was successful may be determined at operation 210. If the authentication was not successful, program flow may end at operation 212. If the authentication was successful, a request for a report descriptor may be received at operation 214. The report descriptor may then be provided at operation 216.

    [0065] A state is reported at operation 218. For example, a sensor state is reported to a sensor processing unit, facilitating lifecycle management. Whether the state corresponds to an error may be determined at operation 220. If the state corresponds to an error, program flow may stop at operation 222. If the state does not correspond to an error, whether there is data to report or a timeout has occurred may be determined at operation 224. For example, the timeout may correspond to a sensor module that is configured to report at predefined intervals. If there is data to report or a timeout has occurred, data may be reported at operation 226. Whether the state has changed may be determined at operation 228. If the state has changed, program flow may proceed to operation 218, report state. If the state has not changed, program flow may proceed to operation 224. If there is no data to report or no timeout has occurred at operation 224, program flow may proceed to operation 228.

    [0066] Thus, a sensor module may be discovered and enumerated in response to being powered on. The sensor status may be monitored and communicated to a sensor processing unit. Thus, lifecycle information may be provided to the sensor processing unit during the lifecycle of the sensor.

    [0067] FIG. 3 illustrates one example 300 of communication between a sensor module, e.g., sensor module 106A, and a sensor processing unit, e.g., sensor processing unit 102. The communication and/or operations illustrated in example 300 may be initiated in response to a powering on of sensor module 106A. The communication and/or operations illustrated in example 300 correspond to an initial interrupt assertion, e.g., in response to a power on of a sensor module, through an interrupt reset following provision of an HID report descriptor response. Example 300 may thus correspond to an enumeration phase, as described herein.

    [0068] Operations of this embodiment, which does not fall under the scope of the claims, may begin with an interrupt assertion at operation 302. A sensor presence indicator may be provided at operation 304. For example, sensor module 106A may be configured to provide an indicator that a sensor has been connected to a sensor slot and is available for use by an application, e.g., sensor application 116. For example, the indicator of a present sensor may be that the sensor responds to READ and/or WRITE I2C commands communicated via the sensor application. A request for an HID descriptor may be communicated at operation 306. The HID descriptor may be retrieved by the sensor module 106A at operation 308. An interrupt related to the HID descriptor may be asserted at operation 310. The HID descriptor may be read at operation 312. The HID descriptor response may be provided at operation 314. The interrupt may be reset at operation 318. For example, the sensor module 106A may be configured to reset the interrupt. The sensor may be authenticated at operation 316. For example, sensor processing unit 102 may be configured to authenticate the sensor, as described herein. A request for a report descriptor may be communicated at operation 320. The report descriptor may be retrieved at operation 322. For example, the report descriptor may be retrieved by sensor logic 136 from a data store 138 included in sensor module 106A. An interrupt related to the report descriptor may be asserted at operation 324. The HID report descriptor may be read at operation 326. The HID report descriptor response may be provided at operation 328. The report descriptor interrupt may be reset at operation 330.

    [0069] Thus, a sensor module, e.g., sensor module 106A, may be discovered and enumerated in response to powering on. The sensor module 106A may be configured to assert an interrupt when there is information (e.g., an HID descriptor, a report descriptor) to be communicated. A sensor processing unit, e.g., sensor processing unit 102, may be configured to service the interrupt by requesting a selected descriptor. The request for a descriptor initiates the sensor module to prepare a descriptor. Following the request for a descriptor, the sensor processing unit may then read the selected descriptor.

    [0070] FIG. 4 illustrates one example 400 of communication between a sensor module, e.g., sensor module 106A, a sensor interface board, e.g., sensor interface board 104, and a sensor processing unit, e.g., sensor processing unit 102. The communication and/or operations illustrated in example 400 correspond to an initial powering up, an initial interrupt assertion (e.g., in response to the powering on of a sensor module), an address determination and associated MUX channel selection and an interrupt reset following provision of an HID descriptor response. Example 400 may thus correspond to a portion of an enumeration phase, as described herein.

    [0071] Operations of this embodiment, which does not fall under the scope of the claims, may begin with a power up command and/or operation 402 from a sensor processing unit, e.g., sensor processing unit 102, to a sensor interface, e.g., sensor interface board 104. The power may then be provided from the sensor interface board 104 to the sensor module 106A at operation 404. A self address resolution may be performed at operation 406. For example, the self address resolution may be performed by sensor module 106A. The self address resolution may include detecting (i.e., determining) the sensor slot address that the sensor is connected to followed by an interrupt that may be asserted at operation 408. For example, the interrupt assertion may be provided by the sensor module 106A to the sensor interface board 104. The interrupt assertion may then be provided from the sensor interface board 104 to the sensor processing unit 102 at operation 410. A control register input/output (I/O) expander may be read at operation 412. For example, the control register I/O expander may be read by the sensor processing unit 102. Control register content may be provided at operation 414. A slot address may be determined at operation 416. An I2C MUX channel may be selected at operation 418. Operations 412, 414 and 418 occur between the sensor processing unit 102 and the sensor interface board 104. Operation 416 may be performed by the sensor processing unit 102. Operations 412, 414, 416 and 418 are configured to determine an address associated with a selected sensor module, e.g., sensor module 106A and to control a MUX, e.g., MUX 144, to select an output that corresponds to the selected sensor module address.

    [0072] A request for an HID descriptor may then be provided by sensor processing unit 102 to sensor module 106A at operation 420. The HID descriptor, i.e., HID descriptor response, may then be provided to the sensor processing unit 102 by sensor module 106A at operation 422. The interrupt may then be reset by the sensor module 106A at operation 424.

    [0073] Thus, in response to powering up a sensor module, an associated address, i.e., slot address, may be determined, a corresponding MUX channel may be selected and an HID descriptor may be requested and received.

    [0074] FIG. 5 illustrates one example 500 of communication between a sensor module, e.g., sensor module 106A, and a sensor processing unit, e.g., sensor processing unit 102. The communication and/or operations illustrated in example 500 correspond to an interrupt assertion, e.g., in response to a change in sensor state, through an interrupt reset following a request for a report descriptor. Example 500 may thus correspond to an operation associated with a lifecycle phase, as described herein.

    [0075] Operations of this embodiment, which does not fall under the scope of the claims, may begin with an interrupt assertion at operation 502. A report may be requested at operation 504. Thus, operation 504 is a report read request. I/P corresponds to 'Input'. A read request is issued first and then the byte values returned represent the results of that read operation, i.e,. the report. Further, a GET corresponds to a read request, e.g., a report request and a SET corresponds to a write request, e.g., sensor configuration change. The interrupt may be reset at operation 506.

    [0076] FIG. 6 illustrates one example 600 of communication between a sensor module, e.g., sensor module 106A, a sensor interface board, e.g., sensor interface board 104, and a sensor processing unit, e.g., sensor processing unit 102. The communication and/or operations illustrated in example 600 correspond to an initial powering up, an initial interrupt assertion, e.g., in response to the powering on of a sensor module, a MUX channel selection through an HID descriptor response. Example 400 may thus correspond to a portion of an enumeration phase, as described herein.

    [0077] Operations of this embodiment, which does not fall under the scope of the claims, may begin with a powering on at operation 602. For example, the power on indication may be provided from a sensor processing unit. A self address resolution based on slot may be performed at operation 604. For example, a sensor module may be configured to determine its address based on a slot in the sensor interface board. In other words, the sensor module may be coupled to the sensor interface board at a slot and operation 604 corresponds to the sensor module determining the address of the slot.

    [0078] An interrupt may be asserted at operation 606. For example, the sensor module may be configured to assert an interrupt via an interrupt line associated with the corresponding slot. A MUX channel may be selected and a request to read an HID descriptor provided at operation 608. An HID descriptor response may be read at operation 610. The HID descriptor response may be read following an interrupt assertion from the sensor module. Operation 612 includes selecting a MUX channel and requesting to read an HID report descriptor. An HID report descriptor response may be read at operation 614. The HID report descriptor response may be read following an interrupt assertion from the sensor module.

    [0079] Thus, in response to powering up a sensor module, an associated address, i.e., slot address, may be determined, a corresponding MUX channel may be selected, an HID descriptor may be requested and received and an HID report descriptor may be requested and received.

    [0080] While the flowchart and examples of FIGS. 2 through 6 illustrate operations according various embodiments, it is to be understood that not all of the operations depicted in FIGS. 2 through 6 are necessary for other embodiments,

    [0081] Referring again to FIG.1, a sensor lifecycle management system, e.g., sensor lifecycle management system 101, may be configured to provide sensor lifecycle management information to a host system, e.g., host system 108, for display to a user via UI 142. The sensor lifecycle management information may include, for example, discovery results, enumeration information as well as sensor type and/or manufacturer information. For example, Table 13 illustrates example log result excerpts from a sensor discovery stage. In this example, a total of 10 sensor modules (and associated sensors) were discovered. In the table SM, corresponds to sensor module.
    Table 13
    Jun 12 10:41:06 984fee016f24 ar-SPU: I2C device was opened
    Jun 12 10:41:26 984fee016f24 ar-SPU: Write 0 to enable power to all SM
    Jun 12 10:41:36 984fee016f24 ar-SPU: Device initialised
    Jun 12 10:41:36 984fee016f24 ar-SPU: I2CInit: PASS
    Jun 12 10:41:36 984fee016f24 ar-SPU: Called getSensorInterrupts
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 0'/J1/ I2C address 38
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 1'/J2/ I2C address 31
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 2'/J3/ I2C address 32
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 3'/J4/ I2C address 33
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 4'/J5/ I2C address 34
    Jun 12 10:41:36 984fee016f24 ar-SPU: Interrupt resolved to be caused by 'Sensor Slot 5'/J6/ I2C address 30
    Jun 12 10:41:36 984fee016f24 ar-SPU: Looped through all the possible Sensor Module interrupt registers
    Jun 12 10:41:36 984fee016f24 ar-SPU: Count is 10


    [0082] Continuing with this example, following detection of the sensors, sensor identification operations are performed to determine a sensor type for each sensor module discovered. Table 14 illustrates sensor type determination results for one sensor of the 10 sensors discovered and illustrated in Table 13. Table 14 further illustrates a successful authentication operation.
    Table 14
    Jun 12 10:41:37 984fee016f24 ar-SPU: Now making a HID request
    Jun 12 10:41:37 984fee016f24 ar-SPU: Expecting to receive a HID response of length: 57 bytes
    Jun 12 10:41:37 984fee016f24 ar-SPU: Auth seed byte 0: f1
    Jun 12 10:41:37 984fee016f24 ar-SPU: Auth seed byte 1: 34
    Jun 12 10:41:37 984fee016f24 ar-SPU: Serial byte 0: 35
    Jun 12 10:41:37 984fee016f24 ar-SPU: Serial byte 1: 36
    Jun 12 10:41:37 984fee016f24 ar-SPU: Auth response byte 0: c4
    Jun 12 10:41:37 984fee016f24 ar-SPU: Auth response byte 1: 2
    Jun 12 10:41:37 984fee016f24 ar-SPU: Using the XOR authentication method
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor was authenticated
    Jun 12 10:41:37 984fee016f24 ar-SPU: Authentication key: 19
    Jun 12 10:41:37 984fee016f24 ar-SPU: HID protocol version: 1
    Jun 12 10:41:37 984fee016f24 ar-SPU: Iterating through 1 sensor descriptors
    Jun 12 10:41:37 984fee016f24 ar-SPU: HID descriptor length: 1a
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor type: PM2P5
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor tag: SENS_PM2P5
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor name: PM2P5
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor sym: PM2PT5
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor report ID[0]: 2a
    Jun 12 10:41:37 984fee016f24 ar-SPU: Sensor report ID[1]: 2c
    Jun 12 10:41:37 984fee016f24 ar-SPU: Manufacturer name: ACME
    Jun 12 10:41:37 984fee016f24 ar-SPU: Serial number: 123456


    [0083] Continuing with this example, after the sensor modules have been detected and authenticated, a summary of the suite available sensors may be provided to the user via the UI 142. Table 15 illustrates an example of the sensor suite summary information provided to the user via host system 108 and UI 142. In this example, the sensor suite includes 10 different sensors
    Table 15
    Jun 12 10:42:08 984fee016f24 ar-SPU: ENUMERATION COMPLETE: 10 sensors have been enumerated
    Jun 12 10:42:08 984fee016f24 ar-SPU: PM2P5
    Jun 12 10:42:08 984fee016f24 ar-SPU: PM10
    Jun 12 10:42:08 984fee016f24 ar-SPU: Nitrogen Dioxide
    Jun 12 10:42:09 984fee016f24 ar-SPU: Carbon Monoxide
    Jun 12 10:42:09 984fee016f24 ar-SPU: Sulphur Dioxide
    Jun 12 10:42:09 984fee016f24 ar-SPU: Nitric Oxide
    Jun 12 10:42:09 984fee016f24 ar-SPU: Temperature
    Jun 12 10:42:09 984fee016f24 ar-SPU: Relative Humidity
    Jun 12 10:42:09 984fee016f24 ar-SPU: Light
    Jun 12 10:42:09 984fee016f24 ar-SPU: Sound


    [0084] Continuing with this example, for a normal operational sensor, program flow may proceed to an observation and reporting phase. The observation and reporting phase corresponds to the lifecycle phase, as described herein. Table 16 illustrates excerpted log information that may be provided during the reporting phase for a fine particulate matter sensor for particle size 2.5 µm (micrometers) or less. The last row in Table 16 includes a reported sensor value which is measured in units of parts per million (ppm). It may be appreciated that the sensor observation data are represented in four-byte IEEE 754 format (binary floating point format) and converted to an ASCII representation of a corresponding decimal value prior to dispatch to the sensor application, e.g., sensor application 116, for display via UI 142.
    Table 16
    Jun 12 10:43:37 984fee016f24 ar-SPU: The received report was for PM2P5
    Jun 12 10:43:37 984fee016f24 ar-SPU: reportResponseFrame->_requestType : 29
    Jun 12 10:43:37 984fee016f24 ar-SPU: reportResponseFrame->_length : 08
    Jun 12 10:43:37 984fee016f24 ar-SPU: reportResponseFrame->_reportID : 2a
    Jun 12 10:43:37 984fee016f24 ar-SPU: reportResponseFrame->_usageID[0] : f5
    Jun 12 10:43:37 984fee016f24 ar-SPU: reportResponseFrame->_usageID[1] : 01
    Jun 12 10:43:37 984fee016f24 ar-SPU: sensor byte[0]: 06
    Jun 12 10:43:37 984fee016f24 ar-SPU: sensor byte[1]: 58
    Jun 12 10:43:37 984fee016f24 ar-SPU: sensor byte[2]: 14
    Jun 12 10:43:37 984fee016f24 ar-SPU: sensor byte[3]: 3e
    Jun 12 10:43:37 984fee016f24 ar-SPU: value: 0.144867


    [0085] Thus, a sensor lifecycle management system, e.g., sensor lifecycle management system 101, may be configured to provide sensor lifecycle management information to a host system, e.g., host system 108, for display to a user via UI 142. The sensor lifecycle management information may include, for example, discovery results, enumeration information as well as sensor type and/or manufacturer information.

    [0086] Thus, an apparatus, method and/or system are configured to manage a respective lifecycle of each of a plurality of sensors. Each sensor module is configured to provide enumeration data, e.g., at power up, and lifecycle data during its respective lifecycle. A sensor module, consistent with the present disclosure, includes a sensor controller and a sensor. The sensor controller is configured to enumerate the sensor module and/or the sensor to a sensor processing unit. The sensor controller is further configured to monitor operation of the sensor and to provide sensor lifecycle information to the sensor processing unit over the lifecycle of the sensor. The sensor is configured to capture measurement data corresponding to a value of an environmental parameter and to provide an electrical signal as output (i.e., sensor data) that is related to the measurement data. The sensor controller is configured to receive the sensor data and to report associated sensor data to the sensor processing unit. The sensor processing unit may then be configured to manage the lifecycle of each associated sensor. Thus, inappropriate action based on erroneous sensor data may be avoided.

    [0087] As used in any embodiment herein, the term "logic" may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices.

    [0088] "Circuitry", as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The logic may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), an application-specific integrated circuit (ASIC), a system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc.

    [0089] The foregoing provides example system architectures and methodologies, however, modifications to the present disclosure are possible. The processor may include one or more processor cores and may be configured to execute system software. System software may include, for example, an operating system. Device memory may include I/O memory buffers configured to store one or more data packets that are to be transmitted by, or received by, a network interface. The operating system (OS) may be configured to manage system resources and control tasks that are run on, e.g., host system 108. For example, the OS may be implemented using Microsoft® Windows®, HP-UX®, Linux®, or UNIX®, although other operating systems may be used. In another example, the OS may be implemented using Android, iOS, Windows Phone® or BlackBerry®.

    [0090] Communication interfaces 114, 134, communication links 103, 107 and/or host system 108 may comply and/or be compatible with one or more communication specifications, standards and/or protocols.

    [0091] For example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with an IPv6 (Internet Protocol version 6) over Low Power Wireless Personal Area Networks (6LoWPAN) standard: RFC (Request for Comments) 6282 , titled Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks, published by the Internet Engineering Task Force (IETF), September 2011, and/or later and/or related versions of this standard.

    [0092] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with IEEE (Institute of Electrical and Electronics Engineers) 802.15.4-2006 standard titled: IEEE Standard for Information technology - Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANS), published in 2006 and/or later and/or related versions of this standard.

    [0093] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with a ZigBee specification and/or standard, published and/or released by the ZigBee Alliance, Inc., including, but not limited to, ZigBee 3.0, draft released November 2014, ZigBee RF4CE, ZigBee IP, and/or ZigBee PRO published in 2012, and/or later and/or related versions of these standards.

    [0094] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with IEEE Std 802.11-2012 standard titled: IEEE Standard for Information technology - Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, published in March 2012 and/or earlier and/or later and/or related versions of this standard, including, for example, IEEE Std 802.11ac™-2013, titled IEEE Standard for Information technology-Telecommunications and information exchange between systems, Local and metropolitan area networks-Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; Amendment 4: Enhancements for Very High Throughput for Operation in Bands below 6 GHz, published by the IEEE, December 2013.

    [0095] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with a Wireless Highway Addressable Remote Transducer (HART) specification and/or standard, published and/or released by IEC under IEC 62591and/or later and/or related versions of these standards.

    [0096] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with Long Term Evolution (LTE), Release 8, released March 2011, by the Third Generation Partnership Project (3GPP) and/or later and/or related versions of these standards, specifications and releases, for example, LTE-Advanced, Release 10, released April 2011.

    [0097] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with an Extended Coverage GSM (EC-GSM) specification and/or standard, published and/or released by 3GPP and/or later and/or related versions of these standards.

    [0098] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with one or more of the Weightless-N open standard, based on a low power wide area (LPWAN) star network architecture, managed by Weightless SIG, Cambridge, United Kingdom; a SIGFOX UNB (Ultra Narrow Band) based radio technology protocol, managed by SIGFOX, Labège France; and/or the LoRaWAN network protocol, e.g., LoRaWAN 1.0 Specification, published by the LoRaAlliance, San Ramon, California, and/or later and/or related versions of these standards, protocols and/or specifications.

    [0099] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with a Thread specification and/or standard, published and/or released by Google and/or later and/or related versions of these protocols

    [0100] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with a Bluetooth specification and/or standard, published and/or released by IEEE and/or later and/or related versions of these protocols

    [0101] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with standard TIA-232 (also and/or formerly known as RS-232), Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, Revision F, dated October 1, 1997 and including amendments and changes through Reaffirmation Notice, December 7, 2012, published by Telecommunications Industry Assn. (TIA), and/or later and/or related versions of this standard.

    [0102] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with standard TIA-485 (also and/or formerly known as RS-485), Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems, Revision A, dated March 1, 1998 and including amendments and changes through Reaffirmation Notice, December 7, 2012, published by TIA, and/or later and/or related versions of this standard.

    [0103] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with one or more protocol specifications published by the NFC Forum, Wakefield, Massachusetts, including, but not limited to, NFC Logical Link Control Protocol (LLCP) 1.2 Technical Specification, adopted March 20, 2014; NFC Digital Protocol Technical Specification 1.1, adopted March 20, 2014; NFC Activity Technical Specification v1.1, adopted January 23, 2014; NFC Simple NDEF Exchange Protocol (SNEP) Technical Specification, adopted August 31, 2011; NFC Analog Technical Specification 1.1, adopted May 27, 2015; NFC Controller Interface (NCI) Technical Specification v1.1, adopted January 23, 2014, and/or later and/or related versions of these protocol specifications.

    [0104] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with a ZWave specification and/or standard, published and/or released by ZWave and/or later and/or related versions of these protocols

    [0105] In another example, communication interfaces 114, 134 and/or communication links 103, 107 may comply and/or be compatible with an ISA100 specification and/or standard, published and/or released by ANSI/ISA , IEC 62734 and/or later and/or related versions of these protocols

    [0106] In another example, communication interface 114 and/or host system 108 may comply and/or be compatible with IEEE Std 802.11-2012 standard titled: IEEE Standard for Information technology - Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, published in March 2012 and/or earlier and/or later and/or related versions of this standard, including, for example, IEEE Std 802.11ac-2013, titled IEEE Standard for Information technology-Telecommunications and information exchange between systems, Local and metropolitan area networks-Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; Amendment 4: Enhancements for Very High Throughput for Operation in Bands below 6 GHz, published by the IEEE, December 2013.

    [0107] Communication interface 114, 134 and/or communication links 103, 107 may comply and/or be compatible with one or more serial communication protocol(s).

    [0108] For example, communication interface 114, 134 and/or communication links 103, 107 may be configured to comply and/or be compatible with one or more serial peripheral interface (SPI) standard(s) and/or protocol(s). SPI is a synchronous serial communication interface typically used for short distance communication.

    [0109] In another example, communication interface 114, 134 and/or communication links 103, 107 may comply and/or be compatible with I2C-bus specification Version 2.1, published in 2000, and maintained by NXP Semiconductors, Inc., and/or later and/or related versions of this specification, for example, document UM10204, I2C-bus specification and user manual, Rev. 6, published April 2014.

    [0110] In another example, communication interface 114, 134 and/or communication links 103, 107 may comply and/or be compatible with System Management Bus (SMBus) Specification, Version 2.0, published by the System Management Interface Forum, Inc., August 2000 and/or Version 3.0, published December 2014, and/or later and/or related versions of this specification.

    [0111] Memory 112, 132 may include one or more of the following types of memory: semiconductor firmware memory, programmable memory, non-volatile memory, read only memory, electrically programmable memory, random access memory, flash memory, magnetic disk memory, and/or optical disk memory. Either additionally or alternatively memory 204 may include other and/or later-developed types of computer-readable memory.

    [0112] Embodiments of the operations described herein may be implemented in a computer-readable storage device having stored thereon instructions that when executed by one or more processors perform the methods. The processor may include, for example, a processing unit and/or programmable circuitry. The storage device may include a machine readable storage device including any type of tangible, non-transitory storage device, for example, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, magnetic or optical cards, or any type of storage devices suitable for storing electronic instructions.

    [0113] In some embodiments, a hardware description language (HDL) may be used to specify circuit and/or logic implementation(s) for the various logic and/or circuitry described herein. For example, in one embodiment the hardware description language may comply or be compatible with a very high speed integrated circuits (VHSIC) hardware description language (VHDL) that may enable semiconductor fabrication of one or more circuits and/or logic described herein. The VHDL may comply or be compatible with IEEE Standard 1076-1987, IEEE Standard 1076.2, IEEE1076.1, IEEE Draft 3.0 of VHDL-2006, IEEE Draft 4.0 of VHDL-2008 and/or other versions of the IEEE VHDL standards and/or other hardware description standards.

    [0114] Thus, operation of one or more sensor arrays may be facilitated. Previously unknown sensors and/or sensor modules may be coupled to a host system and, through enumeration, may be recognized. Further, sensor operation may be monitored throughout the deployment period, i.e., lifecycle information may be acquired, thus avoiding inappropriate action based on erroneous data.


    Claims

    1. An apparatus comprising:

    a sensor module (106A, 106B,...106n) comprising:

    a sensor (122); and

    a sensor controller (120) to enumerate the sensor to a sensor processing unit in response to being powered on, the enumerating comprising communicating enumeration data to the sensor processing unit, the enumeration data comprising one or more of a sensor name, a sensor manufacturer name, a sensor serial number, a hardware version, a firmware version, and/or one or more sensor characteristics, the sensor controller further to monitor operation of the sensor and to provide sensor lifecycle information to the sensor processing unit over the lifecycle of the sensor;

    wherein the sensor controller is further to report a state of the sensor to the sensor processing unit;

    wherein the state of the sensor comprises at least one of:

    - ready, which indicates that the sensor is ready to present data;

    - not available, which indicates that the sensor is not ready to present data;

    - no data, which indicates that no data is available to be presented;

    - initializing, which indicates that the sensor is warning up following a power-on;

    - state unknown;

    - access denied, which indicates that the sensor is preventing access to the measurement data; and

    - error, which indicates that the sensor has encountered an error and/or fault state.


     
    2. The apparatus of claim 1, wherein the sensor controller is further to report sensor data to the sensor processing unit.
     
    3. The apparatus according to claim 1 or 2, wherein the sensor controller is to utilize a communication protocol to enable the sensor controller to communicate at least one of enumeration data, lifecycle data and/or sensor data to the sensor processing unit.
     
    4. The apparatus of claim 3, wherein the communication protocol complies or is compatible with a USB (Universal Serial Bus) HID (Human Interface Device) protocol.
     
    5. The apparatus according to claim 1 or 2, wherein the sensor controller comprises a data store to store at least one of enumeration data, lifecycle data and/or sensor data.
     
    6. A system (100) comprising:

    a sensor processing unit (102); and

    an apparatus according to any one of claims 1 to 5.


     


    Ansprüche

    1. Vorrichtung, Folgendes umfassend:
    ein Sensormodul (106A, 106B, ... 106n), Folgendes umfassend:

    einen Sensor (122) und

    eine Sensorsteuerung (120), um den Sensor in Reaktion auf sein Einschalten gegenüber einer Sensorverarbeitungseinheit zu spezifizieren, wobei das Spezifizieren das Kommunizieren von Spezifizierungsdaten an die Sensorverarbeitungseinheit umfasst, wobei die Spezifizierungsdaten eines oder mehreres von einem Sensornamen, einem Sensorherstellernamen, einer Sensorseriennummer, einer Hardwareversion, einer Firmwareversion und/oder eine oder mehrere Sensoreigenschaften umfassen, wobei die Sensorsteuerung ferner dafür vorgesehen ist, den Betrieb des Sensors zu überwachen und im Laufe der Lebensdauer Sensorlebensdauerinformationen des Sensors für die Sensorverarbeitungseinheit bereitzustellen,

    wobei die Sensorsteuerung ferner dafür vorgesehen ist, einen Zustand des Sensors an die Sensorverarbeitungseinheit zu melden,

    wobei der Zustand des Sensors mindestens eines des Folgenden umfasst:

    - bereit, was angibt, dass der Sensor bereit ist, Daten zu präsentieren,

    - nicht verfügbar, was angibt, dass der Sensor nicht bereit ist, Daten zu präsentieren,

    - keine Daten, was angibt, dass keine Daten zum Präsentieren verfügbar sind,

    - Initialisierung, was angibt, dass sich der Sensor nach einem Einschalten aufwärmt,

    - Zustand unbekannt,

    - Zugriff verweigert, was angibt, dass der Sensor den Zugriff auf die Messdaten verhindert, und

    - Fehler, was angibt, dass an dem Sensor ein Fehler- und/oder ein Störungszustand aufgetreten ist.


     
    2. Vorrichtung nach Anspruch 1, wobei die Sensorsteuerung ferner dafür vorgesehen ist, Sensordaten an die Sensorverarbeitungseinheit zu melden.
     
    3. Vorrichtung nach Anspruch 1 oder 2, wobei die Sensorsteuerung ferner dafür vorgesehen ist, ein Kommunikationsprotokoll zu verwenden, um die Sensorsteuerung in die Lage zu versetzen, mindestens eines von Spezifizierungsdaten, Lebensdauerdaten und/oder Sensordaten an die Sensorverarbeitungseinheit zu kommunizieren.
     
    4. Vorrichtung nach Anspruch 3, wobei das Kommunikationsprotokoll ein USB(Universal Serial Bus)-HID(Human Interface Device)-Protokoll erfüllt oder mit diesem kompatibel ist.
     
    5. Vorrichtung nach Anspruch 1 oder 2, wobei die Sensorsteuerung einen Datenspeicher zum Speichern mindestens eines von Spezifizierungsdaten, Lebensdauerdaten und/oder Sensordaten umfasst.
     
    6. System (100), Folgendes umfassend:

    eine Sensorverarbeitungseinheit (102) und

    eine Vorrichtung nach einem der Ansprüche 1 bis 5.


     


    Revendications

    1. Appareil comprenant :
    un module de capteur (106A, 106B, ...106n) comprenant :

    un capteur (122) ; et

    un contrôleur de capteur (120) pour dénombrer le capteur auprès d'une unité de traitement de capteur en réponse à sa mise sous tension, le dénombrement comprenant la communication de données de dénombrement à l'unité de traitement de capteur, les données de dénombrement comprenant un ou plusieurs éléments parmi un nom de capteur, un nom de fabricant de capteur, un numéro de série de capteur,

    une version de matériel, une version de micrologiciel, et/ou une ou plusieurs caractéristiques de capteur, le contrôleur de capteur devant en outre surveiller le fonctionnement du capteur et fournir des informations de cycle de vie de capteur à l'unité de traitement de capteur sur le cycle de vie du capteur ;

    où le contrôleur de capteur est en outre destiné à signaler un état du capteur à l'unité de traitement de capteur ;

    où l'état du capteur comprend au moins l'un des états suivants :

    - « prêt », qui indique que le capteur est prêt à présenter des données ;

    - « non disponible », qui indique que le capteur n'est pas prêt à présenter des données ;

    - « aucune donnée », qui indique qu'aucune donnée n'est disponible pour être présentée ;

    - « initialisation », qui indique que le capteur est en alerte après une mise sous tension ;

    - « état inconnu » ;

    - « accès refusé », qui indique que le capteur empêche l'accès aux données de mesure ; et

    - « erreur », qui indique que le capteur a rencontré une erreur et/ou un état de défaut.


     
    2. Appareil selon la revendication 1, dans lequel le contrôleur de capteur est en outre destiné à rapporter les données de capteur à l'unité de traitement de capteur.
     
    3. Appareil selon la revendication 1 ou la revendication 2, dans lequel le contrôleur de capteur doit utiliser un protocole de communication pour permettre au contrôleur de capteur de communiquer au moins une des données de dénombrement, des données de cycle de vie et/ou des données de capteur à l'unité de traitement de capteur.
     
    4. Appareil selon la revendication 3, dans lequel le protocole de communication est conforme ou compatible avec un protocole USB (Universal Serial Bus) HID (Human Interface Device).
     
    5. Appareil selon la revendication 1 ou la revendication 2, dans lequel le contrôleur de capteur comprend une mémoire de données pour stocker au moins une des données d'énumération, des données de cycle de vie et/ou des données de capteur.
     
    6. Système (100) comprenant :

    une unité de traitement de capteur (102) ; et

    un appareil selon l'une quelconque des revendications 1 à 5.


     




    Drawing























    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description




    Non-patent literature cited in the description